Why contract compliance eats treasury hours
Twenty six days a year. That is how much senior treasurer time a mid-market AP function loses to contract terms that have drifted across three systems. The hours are invisible until someone gets paid wrong. Why we made the boring choice.
The treasurer who runs payments at a mid-market industrial company told me she spends about a day every fortnight on contracts. Not negotiating them. Not signing them. Reading them, cross checking them against payment terms in the AP system, and chasing the buyer who set up the supplier to fix the bits that do not match.
A day every two weeks is twenty six days a year. A month of one senior treasurer's time, on a task that is invisible until someone gets paid wrong.
Where the gap is
Contracts and payments live in different systems. The contract sits in a folder, or a contract management tool, or a SharePoint site somebody set up four years ago. The payment terms get retyped into the AP system when the supplier is created, and again when an invoice is loaded, and again when the payment is approved. By the third retype the data has drifted.
The mismatch shows up in small ways at first. A supplier expects net 30 because that is what the contract said. The AP system has net 45 because that is what got typed in. The first invoice goes out late, the supplier emails the buyer, the buyer asks the treasurer to "fix it for this one", and now the rule has an exception that nobody has written down.
Multiply that exception by a few hundred suppliers and you have the data condition most mid-market AP teams actually operate in. It is not chaos. It is worse than chaos. It is order with a thousand undocumented exceptions.
What compliance actually costs
Hard cost: penalties, missed early-payment discounts, the occasional emergency wire. Easy to spreadsheet. Usually somewhere between half a percent and one percent of spend.
Soft cost: the senior treasurer's day every fortnight, the buyer who got pulled in to resolve a clash they did not create, the supplier-relationship damage from being late on payments that should have been on time, the audit findings that take three months to clear. Harder to spreadsheet. Bigger.
The soft cost is the one that drove the design decisions on the Calabash AP side. We do not have a contract management module. We do not want one. What we have is a payment terms field on the supplier business partner that is the only place those terms live, with a write rule that ties any override on an invoice back to a workflow step a treasury operator approved by name. If the contract says net 30, the supplier BP record says net 30, and any deviation is logged and reviewable.
It sounds obvious. Most AP systems do not do this. They let a buyer enter custom terms on each PO without writing back to the supplier record. The drift is built into the workflow.
The boring conclusion
Compliance work that you can ignore in the small is the compliance work that destroys you at scale. The reason we are building the buyer side first is that this is where the discipline has to live. The treasurer cannot enforce contract terms she does not have. The buyer can. We are building the rails so the buyer can do it without a second tool, and the treasurer can trust the data on the other end.
If you have a different opinion about how this should work, I want to hear it. We are still shaping these primitives and the half-written exceptions in your AP system are the most useful design input I can think of. Sign up at calabash.app/b2b and tell us what your version of this looks like.
