Building smarter cash and AP operations

Every conversation about smarter AP I have ever been in turns into a list of features. Automated approvals. OCR. Three way match. Vendor portal. Spend analytics. The list is real. It is also the wrong frame.

Smarter AP is not a list of features. It is the consequence of getting four primitives right. If the primitives are right, most of the features show up almost for free. If the primitives are wrong, the features become bandages on a model that fights you.

One. The supplier business partner is the unit

Most AP systems organise their world around the document. The invoice is the thing. The PO is the thing. The payment is the thing. The supplier is a field on those things.

That model breaks in mid-market businesses because the supplier turns up under three slightly different names in three different documents. The matching never catches up. Reconciliation is permanent.

Calabash organises its world around the supplier business partner. The BP is the unit. Invoices, POs, payments, contracts, bank accounts, and KYC records all hang off it. Document-level data is enriched at the moment of creation with the BP identity, and any subsequent mismatch surfaces as a workflow exception, not a silent data drift. The cost of that decision is one extra primitive in the data model. The benefit is that everything downstream of it stops being a reconciliation problem.

Two. Bank accounts live on two parallel rails

Self-service bank account capture, by the supplier through onboarding, sits on one table. Treasury-vetted accounts, capable of receiving payment runs, sit on another. They do not auto-promote. A treasury operator promotes a profile account into the vetted table after a verification step, and any change to a vetted account requires re-verification.

This is the single most defensive thing in the architecture. Most invoice fraud against mid-market businesses runs through bank account substitution. When the supplier's "real" bank details and the supplier's "payable to" bank details live on the same row in the same table, a malicious actor only needs to win one battle. When they live on two rails with explicit treasury control, the attack surface collapses.

Three. Workflow steps are rows, not states

Every step in every approval flow is a row in a workflow table. Not a state stored on a parent record. A row, with an actor, a timestamp, a decision, and a payload of what was approved.

This sounds like a small modelling choice. It is the single biggest factor in whether you can audit your AP flow without weeks of work. State stored on a parent record is invisible once the next state writes over it. A row is forever. Auditors love rows. So do treasurers.

Four. The cash forecast reads live invoice and PO data

The treasurer's cash forecast does not run on a CSV extract dropped in a folder. It reads live from the AP database. Payment scheduling, currency timing, early-payment-discount capture, and late-payment risk all live inside the forecast as decisions the treasurer can act on with the data that is actually true at the moment she looks.

This requires that AP and treasury share the same data layer. They cannot be two systems sending each other extracts. The whole point of building buyer-side AP and treasury together at Calabash is that this primitive is the easy one when they live in the same store, and is the impossible one when they do not.

The features come second

OCR shows up because the BP-as-unit primitive makes it useful. Three way match becomes trivial because the workflow rows already record what was approved. Vendor portals are clean because the data they show is the data treasury has verified. Spend analytics is reliable because reconciliation is not catching up to the data, it is reading the data.

If you are evaluating an AP system, look at the primitives before the features. Ask how the supplier identity is held. Ask how bank accounts are modelled. Ask whether workflow history is a row or a state. Ask whether AP and treasury read the same data. The answers tell you what the next four years of operating that system will feel like. Sign up at calabash.app/b2b if you want to compare what we have built against what you have today.