The payments your ERP can’t see

Most finance teams have a reconciliation routine. Pull the bank statement. Match it against the ledger. Find the entries that didn’t go through the ERP and allocate them. It runs at month-end, sometimes at quarter-end. It works. 

It is also the visible end of something more structural, and the structural thing is worth naming. 

A category of payments leaves the bank without ever passing through the ERP. Rent. Direct debits. Standing orders. Lease payments. Recurring contractor fees. The bank executes them on its own schedule. There is no transaction for the system to record, no instruction for it to track, no entry for it to reconcile against. The reconciliation routine exists because the gap exists, and the gap is permanent. 

It is not an ERP failure. It is the boundary the ERP was built inside. 

It is a boundary, not a failure 

ERPs are built around instructing the bank. You receive an invoice, the system records the obligation, the system sends payment instructions, the bank confirms. The loop is closed at every step. That is the architecture, and for the majority of payments it is the right architecture. 

Bank-initiated payments break the loop because there is nothing to instruct. A standing order executes on the bank’s own schedule, regardless of what the ERP knows or doesn’t know. There is no request sent. There is no record generated. From the ERP’s point of view, the money simply leaves. 

The fix has historically been manual. Someone in finance reviews the bank statement, identifies the entries that don’t reconcile, allocates them, and writes them up. It works. It also depends entirely on the person doing it being there. 

When the person isn’t there, things get missed. And when things get missed, they tend to be missed in two distinct ways. 

Two failure patterns 

The first is what happens when a payment doesn’t go out. The second is what happens when a payment does go out but nobody is counting. 

When a payment doesn’t go out 

Recurring obligations have fixed dates. Rent on the first. Lease payments on the fifteenth. Contractor payroll at month-end. In a large finance function those obligations get distributed: one person handles rent, another handles contractors, another handles facilities. Each one knows their list, runs their schedule, makes their payments. 

When that person is on leave, off sick, or has left the company, the schedule doesn’t run on its own. There is no automated trigger to fall back on, because the trigger was them. And because there is no transaction sitting in a queue waiting for action, AP usually doesn’t know anything has stopped. The first signal is external. A landlord calls about late rent. A leasing company applies a charge. A contractor asks where their wages are. 

The contractor case is the sharpest. If the person tracking the contractor list is out and nobody else has the list, the contractors don’t get paid. They notice. AP notices when they’re told. 

“If they’re out, nobody’s actually really going to check to make sure they’ve done it.” 

This is the texture of the failure. Not a system error, not a missed approval, not a workflow exception. A quiet absence that nobody is positioned to spot. 

When a payment goes out but nobody is counting 

The second pattern works in the other direction. Spend that runs through the year against a budget set at the start of the year. Marketing. IT support. Travel. Facilities. Each individual purchase is legitimate. Each invoice is processed cleanly. The budget itself, though, lives in a spreadsheet that nobody looks at until somebody adds the numbers up. 

The numbers usually get added up at the end of the year. Sometimes after the budget has already been spent. Sometimes after it has been spent twice over. 

The CFO finds out in retrospect, in a meeting that starts with someone saying “actually, that marketing event cost us a fortune, but we didn’t realise until we had spent everything.” 

Recurring non-PO spend is part of every finance function. It is one of the categories where finance teams routinely don’t know what they don’t know. 

Why this matters now 

The structural blind spot has always existed. What has changed is its size. 

McKinsey’s research on retailers finds that indirect costs, the goods and services a business buys but does not resell, are equivalent to 10 to 15 percent of sales on average, with a lack of spending visibility named as one of the four core challenges. A growing share of that indirect spend lands as recurring, non-PO obligations: subscriptions, services, contracted resources, leases. A larger fraction of total spend now sits in the category the ERP cannot see. 

Manual reconciliation worked when recurring non-PO obligations were a small slice of the picture. As that slice grows, the cost of finding things out late grows with it. 

What good looks like 

Both failure patterns have the same fix at the conceptual level. Bring the obligation into a deliberate, visible workflow before the bank runs it. Generate the record the ERP would otherwise be missing. Let the same approvals, accruals, and reporting that apply to every other invoice apply to this one. 

In practice the resolved state has two halves. 

For installment-based obligations: payments land on the right date, every date, regardless of who is in the office. No late fees. No supplier relationship damage. No contractor wondering where their wages are. The data is in the ledger before the bank moves the money, not after. 

For budget-based obligations: the budget lives, rather than sitting in a spreadsheet at the start of the year. Spend is checked against the cap as it happens. Approval flags fire at thresholds, not at year-end. Forecasting becomes possible because the data is current. 

The pattern in both halves is the same. The information moves from after-the-fact to in-the-moment. From retrospective to prospective. From reactive to proactive. 

This is what active control looks like in a category most ERPs were never built to see. The earlier piece in this series argued that automation without active checks leaves you working in a bubble. The same logic applies here, with one difference. The bubble isn’t created by stale validations. It is created by an absence of records altogether. 

The reframe 

There are two ways to handle recurring non-PO obligations. Treat each one as a reconciliation exercise after the fact. Or surface them deliberately, give them a structure, and let the ERP record them the way it records every other invoice. 

The choice isn’t between an ERP that works and an ERP that doesn’t. It’s between leaving a category of spend outside the system and bringing it inside. The payment is going to happen on the bank’s schedule whether the ERP knows or not. The question is whether the ERP knows. 

“We’re adding visibility to the invisible transaction.” 

That is the work. Not replacing what the ERP does well. Surfacing the obligations it was never asked to see, before they show up on the statement, before someone has to find them, before the absence becomes a phone call. 

The honest takeaway for a finance leader is not “your controls have failed.” It’s “there is a category of spend you may not have looked at in this way, and the longer you don’t, the more it costs to find out where it went.” 

How strong are your AP controls? Answer 12 questions in under 5 minutes to uncover hidden AP control gaps across supplier onboarding, approvals, payment workflows, and audit readiness.