Most AP automation tools focus on scanning and approvals. But for companies with 20+ locations, the real time sink is something nobody talks about: coding.
If you run accounts payable for a single-entity company, invoice coding is straightforward. One entity, a handful of GL accounts, maybe a couple of cost centers. You could train a new hire on it in an afternoon.
Now multiply that by 50 locations across 12 legal entities.
Suddenly every invoice becomes a mini-research project. Which site ordered this? Which entity owns that site? What GL account does it map to? What cost center does it roll up under?
That’s four coding decisions per invoice - site, entity, GL code, and cost center - and each one requires context that lives somewhere different.
I’ve spent the last year talking to finance leaders at multi-site companies - parking operators, restaurant groups, dental DSOs, hotel management companies, fitness chains. The same problem comes up in almost every conversation. Not scanning. Not approvals. Not payments. Coding.
The math nobody does
Let’s run the numbers for a 50-location operator.
A typical location generates 3-5 vendor invoices per week. Call it 4. That’s 200 invoices per week across the portfolio. Each invoice needs those 4 coding fields populated before it can hit the ERP. That’s 800 coding decisions per week.
If your AP clerk spends 90 seconds per invoice just on coding - looking up the location, confirming the entity, selecting the GL account, assigning the cost center - that’s 5 hours per week on pure data entry. For one person. And that assumes no exceptions.
According to IOFM benchmarking data, manual AP processing costs between $12 and $18 per invoice when you include labor, coding time, approval routing, exception handling, and compliance overhead. Best-in-class automated teams get that down to $2-4 per invoice - an 80%+ reduction.
But here’s the part that gets lost: most of the savings from automation come from the coding step, not the scanning or approval steps. OCR and scan-to-capture have been around for 20 years. Approval routing is a solved problem. The coding step is where manual effort concentrates in multi-entity environments.
Where the complexity lives
Single-entity AP is a lookup problem. You see an invoice from Staples, you code it to Office Supplies, done.
Multi-entity AP is a mapping problem. You see an invoice from Staples, and you need to figure out:
Which site? Did the Chicago office order this, or the Denver office? The invoice might say “Ship to: 1420 N Wells St” and your team needs to know that’s Site 14, not Site 7 (which is two blocks away).
Which entity? Site 14 might sit under Entity 3 (Midwest Holdings LLC) while Site 7 is under Entity 1 (Central Ops Inc). Get this wrong and your consolidation is off.
Which GL account? Office supplies for a corporate location might be 6500-100, but for a field location it could be 6500-200. Or maybe this particular Staples order was actually for cleaning supplies, which is a different GL entirely.
Which cost center? Does this roll up under the regional manager’s P&L, the corporate overhead bucket, or a specific project code?
That’s four decisions, each dependent on context that usually lives in a spreadsheet, a person’s head, or both.
The spreadsheet that runs your AP
Almost every multi-site finance team I’ve talked to has some version of “the spreadsheet.” It goes by different names - Location Mapping, Entity Lookup, the Coding Sheet, or just “Sarah’s file.”
It’s usually an Excel workbook with tabs that cross-reference site addresses to entity numbers, entity numbers to GL structures, and GL structures to cost centers. Sometimes it includes vendor-level defaults (Sysco always goes to 5100, Cintas always goes to 6300).
This spreadsheet is the institutional knowledge of the AP function compressed into a single file. And it creates three problems:
Single point of failure. When the person who maintains the spreadsheet goes on vacation, gets sick, or leaves the company, AP grinds to a halt. I’ve heard this exact story from at least a dozen finance leaders. One controller told me their AP fell two weeks behind when their senior clerk retired because nobody else knew the coding logic.
Version control. New locations get added, entities get restructured, GL accounts change during year-end. The spreadsheet drifts out of sync with the ERP. Invoices get coded to closed accounts, to entities that have been merged, or to cost centers that no longer exist. These errors don’t surface until the close, when they become reconciling items.
Doesn’t scale. A 20-location company can manage with a spreadsheet. A 100-location company cannot. But many companies grow from 20 to 100 over a few years - especially PE-backed roll-ups - and the spreadsheet just accumulates tabs until it becomes unmanageable.
Why traditional AP automation doesn’t solve this
Most AP automation platforms focus on three things: capture (OCR/scanning), routing (approval workflows), and payment (ACH/check runs). These are important, but they don’t touch the coding problem.
Some platforms offer “smart coding” or “AI-powered GL assignment,” but most of these work at the single-entity level. They learn that Staples = Office Supplies and auto-assign the GL code. That’s useful, but it doesn’t solve the multi-dimensional mapping problem.
For a multi-site company, the coding engine needs to understand not just what was purchased, but where it was delivered, which entity owns that location, and how that entity’s chart of accounts is structured. That’s a fundamentally different problem than single-entity GL assignment.
The result is that many multi-site companies implement AP automation and still end up with a team of people manually coding invoices. They’ve automated the scan and the approval, but the bottleneck just shifted to coding.
What actually fixes it
The coding problem in multi-site AP is pattern-based. Vendor X ships to Site Y under Entity Z, coded to GL account A and cost center B. These patterns repeat with high consistency - often 85-90% of invoices follow established patterns.
The solution isn’t a smarter spreadsheet. It’s a system that learns the coding patterns from historical invoice data and pre-assigns all four coding dimensions before a human touches the invoice.
This means:
The AP clerk reviews coding instead of researching it. They see an invoice pre-coded with site, entity, GL, and cost center, and either confirm or override. Confirming takes 5 seconds. Researching from scratch takes 90 seconds. That’s an 18x difference per invoice.
New locations inherit patterns. When you acquire a new site, the system can apply coding patterns from similar locations in the portfolio. Day one, your AP team isn’t starting from zero.
The spreadsheet becomes a backup, not the primary system. Institutional knowledge gets encoded into the automation layer instead of living in a file on someone’s desktop.
Exception handling gets focused. Instead of every invoice requiring manual coding, only the true exceptions - new vendors, unusual purchases, ambiguous deliveries - need human attention. The 85-90% that follow patterns get coded automatically.
The metric that matters
Multi-site finance teams track a lot of KPIs, but the one that tells you whether your AP coding process is working is simple: time from invoice receipt to ERP posting.
If that number is measured in days, your coding process is the bottleneck. If it’s measured in hours, you’ve solved it.
For context, best-in-class multi-site AP teams post invoices within 24 hours of receipt. The median is closer to 5-7 business days. The difference is almost entirely attributable to the coding step.
What to do about it
If you’re running AP for a multi-site or multi-entity company and recognize any of what I’ve described, here are three things to evaluate:
Audit your coding time. Have your AP team track how many minutes per invoice they spend on coding versus other tasks (scanning, approvals, payment processing) for one week. Most teams are surprised by the split.
Map your coding dependencies. Document where the information lives for each coding dimension. If the answer to “how does your team know which entity this invoice belongs to” is “they just know” or “it’s in a spreadsheet,” you’ve identified your risk.
Evaluate automation that understands multi-entity structures. Not all AP automation is built for multi-site complexity. Ask vendors specifically about multi-entity coding, not just GL assignment. There’s a meaningful difference.
I write about AP operations at multi-site companies. If your team is spending more time coding invoices than reviewing them, I’d be interested to hear how you’re handling it.