You'd think by now we'd have figured out how to pay people.
We can settle a securities trade in T+1, move money across borders in seconds, and tap a watch to buy coffee. Yet somewhere between a buyer approving an invoice and a supplier actually getting paid, things go sideways with remarkable consistency. Payments get returned. Checks get lost. Vendors call to ask where their money is. AP teams spend hours — sometimes days — manually tracking down what should have been a routine transaction.
This isn't a technology failure. It's an orchestration failure. And it's the problem that every AP company says they're solving, and very few have actually cracked.
The world as it is (not as anyone wants it)
Let's start with an uncomfortable truth: checks are still happening.
Not because anyone loves them. Not because a CFO somewhere made a deliberate strategic choice to mail paper. They happen because the alternatives weren't available, the supplier wasn't enrolled, the payment fell through the cracks, and the path of least resistance ran straight to a check printer.
Every AP platform operator we've talked to says the same thing: "We wish checks weren't even an option." And yet, for most platforms, a meaningful percentage of payment volume still ends there. Sometimes 20%. Sometimes more. That number doesn't shrink by wishing — it shrinks by building something better upstream.
That something better is payment orchestration. And doing it well is genuinely hard.
The waterfall — what good actually looks like
When a payment file hits a modern AP payments engine, here's what should happen. The engine ingests the file and immediately starts making decisions — not batch decisions, not end-of-day decisions, but payment-by-payment decisions in real time, informed by everything it knows about that transaction.
What does it know? Quite a bit, if it's built right: buyer preferences, supplier preferences and agreements, whether the bank account is validated, the due date, and the payment-level economics — what each option costs, what revenue each option generates. A good orchestration engine understands that not all payments are created equal, and routes accordingly.
Armed with all of this, the engine produces payment instructions — not just a payment method. It takes a single payment request and may split it, sequence it, or redirect it based on what it knows. The waterfall, top to bottom:
- Buyer-directed payment preference. If the buyer has a contractual or preferred method, it goes there first.
- Virtual card — straight-through processing (STP). Does the supplier accept virtual card automatically, without human intervention? Send it. This is the highest-value outcome for most AP platforms.
- Virtual card — email-delivered. Supplier takes cards but needs a manual acceptance flow. Still a card, still monetizable, slightly more friction.
- Faster payment rails — RTP / FedNow. Has the supplier signed up for real-time payment? Does the transaction fit the parameters? Move it there.
- Enhanced ACH with full remittance. A properly enriched ACH with clean, structured remittance data solves a real pain point for supplier AR teams.
- Aggregated payment products. Some suppliers receive high volume from multiple buyers. Netting payments across sources reduces noise on their end.
- Check alternatives. Supplier isn't on any of the above, but is eligible for a digital check, push-to-card, or real-time credit.
- Aggregated check. Multiple payments to the same supplier in one envelope. At least it's consolidated.
- Mailed individual paper check. The end of the waterfall. The thing nobody wanted. But the payment still gets made.
The part nobody talks about — what happens when it goes wrong
Here's where most platforms fall apart.
A virtual card gets issued. The supplier doesn't accept it within the window. The card expires, or the authorization fails, or the supplier's AP team accidentally discards the email. Now what?
If your orchestration engine is built correctly, the answer is: nothing dramatic. The engine detects the failure, reassesses the payment, and routes it down the waterfall to the next best option. It's a retry — automated, silent, handled.
If your orchestration engine is not built correctly — which is most of the market — the answer is: a human touches it. Someone on an operations team gets an exception report. They look up the supplier. They figure out what happened. They manually redirect the payment. This takes time, introduces error, and scales terribly.
Worse: some platforms, when they can't resolve it, return the payment to the buyer. The money goes back. The buyer's accounting system records a void. The supplier never got paid. The invoice is past due. Somebody gets an angry call. Nobody is happy.
This is the operational nightmare hiding inside most AP payment platforms. The happy path is clean. The unhappy path — returns, expirations, failed authorizations, unvalidated accounts — is where the wheels come off.
Sophisticated payment orchestration handles the unhappy path programmatically. It doesn't rely on operations teams to catch exceptions. It doesn't stop the payment and send it backwards. It reroutes, retries, and keeps moving — with a full audit trail so everyone knows what happened and why.