Some vendors send a single payable amount on the invoice and the detail you actually need for coding in a separate file. The invoice is perfectly readable. The accounting is not finished. Better extraction on the PDF does not fix this, because the PDF was never the problem. What fixes it is getting the allocation logic out of a monthly spreadsheet and attaching it to the vendor, so the breakdown arrives as coded bill lines instead of as homework.
One accounting team had been running exactly this for years: a logistics vendor billing one figure, a 90 row export arriving beside it, and the better part of an afternoon every month spent turning one into the other. Their story is below. It matters most if you have vendors who bill a total and send detail separately, if the same vendor codes differently across your entities, or if the allocation currently lives in a spreadsheet only one person understands. That describes freight, telecom, utilities, staffing and facilities suppliers at most mid market companies, which is usually where the largest invoices are.
The shape of the problem
A logistics vendor bills one number at the bottom of the page. Shipping, storage, fuel, accessorials, all of it collapsed into a single payable figure. The breakdown arrives separately as a system export.
The team mentioned above walked us through their version. That export ran to roughly 90 rows and 27 columns, one line per shipment. Charge types sat in one set of columns. Amounts sat in another. Nothing in the file matched how the company books its costs, and nothing in it could be pasted anywhere useful.
The monthly ritual looked like this:
- Open the lump sum invoice.
- Open the export.
- Rebuild the allocation with SUMIFS across specific charge columns, or with Power Query if someone had built it properly.
- Fold 27 columns into roughly five expense categories, with some rows included only when the destination met a condition.
- Decide where each result lands in the general ledger and how it gets taxed.
- Key or paste the results into the ERP as bill lines.
A bookkeeper had built all of that logic into a spreadsheet and ran it every cycle. The spreadsheet worked. It was also the single point of failure for a recurring monthly close, it lived on one person's machine, and nobody else on the team could have reproduced it from scratch if that person had been away at month end.
Why coding from history does not solve it
Most AP tools approach coding by learning from what people entered last time. Capture the header, capture whatever lines exist, suggest a GL account based on precedent, move on.
That works when the vendor’s document already resembles the journal entry. It does not work here, for two reasons.
First, there are no lines on the invoice to learn from. There is one number. History based coding can suggest an account for the lump sum, which is precisely the outcome the finance team is trying to avoid.
Second, and more awkwardly, history based coding copies what was typed last time rather than what was meant. If last month’s spreadsheet work was rushed, the pattern inherits the rush. The system becomes very good at reproducing an error nobody has noticed yet.
Even with both of those handled, a harder issue remains. A flawless SUMIFS workbook does not know that a given charge column maps to a freight account under one entity and a different class under another. Someone still has to finish the accounting, and that someone is usually the same bookkeeper.
What this costs, and why it hides
Work like this rarely shows up in an AP metric, because the invoice is never technically an exception. It processes. It just processes slowly, through a person, every single month.
For context on what surrounding conditions look like, Ardent Partners’ Accounts Payable Metrics That Matter in 2025 reports an average cost of $9.40 to process a single invoice against $2.78 for best in class teams, and an average touchless processing rate of 32.6 percent against 49.2 percent for top performers. Invoices requiring manual allocation sit permanently outside the touchless share, no matter how good the rest of the stack is.
The more useful number is the one you already have. Count the vendors whose invoices cannot be coded without opening a second file, then multiply by the minutes it takes each cycle. Most teams have between three and a dozen of these relationships, and they are usually the largest suppliers, which is why the spreadsheet survives year after year.
Find yours in ten minutes
Run this over your last month of payables.
What we built, and the decision behind it
We did not build a better answer about the spreadsheet. A chat panel explaining what the file contains is not useful to someone who needs coded bill lines in an ERP.
What we built is a place to save the team’s allocation logic against the vendor, written as plain language instructions rather than as a configuration screen. Something close to: for this vendor, calculate five expense categories using these charge columns, exclude records of this type, apply this tax treatment to each result. Upload the document and the rules run. What comes out is structured bill lines inside the bill record, with GL and tax coding already populated and waiting for review.
The rules stay attached to the vendor, so the next export from them gets the same treatment automatically. The source document sits beside the result, and anyone on the team can open it and change something before approval.
Two design choices matter more than the feature itself. The first is where the output lands. The result has to be a bill the ERP can receive, with lines and coding, not an explanation of what the system thinks. The second is visibility on inference. Where coding was filled by resemblance to similar past invoices rather than by an explicit rule, we mark it, so a reviewer knows which fields deserve a second look.
In demos this looks deliberately unglamorous. A dense spreadsheet becomes five coded lines. The reaction is usually recognition rather than surprise, because the people watching have been living inside those formulas for years.
None of this required a separate tool. Finofo runs accounts payable, expense management and purchasing on a single AI native engine, built in Calgary for the documents Canadian finance teams actually process. What is described here applies to card receipts and purchase orders exactly as it applies to vendor invoices, with one approval model and one posting path into the ERP.
What stays with your team
Finofo is designed so that the people who own the accounting stay in control of it. A few things are deliberately yours.
The first rule for a new vendor is written by your team, because it is your accounting logic. Finofo does not guess what your five expense categories should be. Its job is to make sure that logic is written once, in plain language, and then never rebuilt from memory again.
When a vendor redesigns their export, the change is caught rather than absorbed. The rule stops matching cleanly, the bill is held for review, and someone on the team updates the instruction. Nothing posts on autopilot because a supplier changed a report layout. That is a control, and it is the reason the approach is safe to rely on at month end.
The invoice can stay a lump sum
If your most painful vendors send a single payable figure and a file that contains the real accounting, the bottleneck is not extraction accuracy on the total. The bottleneck is that your allocation logic lives outside the bill, in a spreadsheet, maintained by one person.
Put the logic on the vendor. The invoice can carry on being one number. If you want to see it with your own export rather than a sample, bring the ugliest one you have to a demo. Those are the ones that make the case.
Frequently asked questions
How do you code a lump sum invoice that has no line items?
You cannot code it from the invoice alone, because the detail is not there. The practical approach is to capture the allocation logic your team already applies to that vendor’s supporting file, store it against the vendor, and generate coded bill lines from it. The invoice total then reconciles against the sum of those lines. Finofo stores that logic as plain language rules on the vendor record and produces the coded lines inside the bill.
Can AP automation read a CSV or spreadsheet attachment?
It depends on the tool and the format. Many systems are built around invoice shaped documents and treat a data export as an unclassified attachment. Ask specifically whether supporting files can drive coding, or whether they are only stored alongside the bill. In Finofo, a supporting export is the input to a vendor rule, not just an attachment, so it drives the coding rather than sitting next to it.
Why does the same vendor get coded differently across entities?
Because the cost belongs to different parts of the business depending on which entity or property received the service. This is normal in multi entity organisations, and it is the detail most template based automation handles poorly, since it assumes one vendor maps to one coding pattern. Finofo's vendor rules carry entity and business unit as conditions, so one vendor can code differently per entity without a separate rule set for each.
About Finofo
Finofo is the AI native platform built in Calgary for Canadian finance teams. It brings accounts payable, expense management and purchasing onto one engine, on the cards, bank and ERP a business already uses, with line level extraction, Canadian tax handling and approval workflows designed for multi entity, multi province operations. Finofo does the verification. Finance keeps the judgment. Learn more at finofo.com.
