A finance lead at a multi-division wholesale distributor stopped a demo on a line item and pointed at a vendor account number. Beauty and professional products. Sage in the stack. Four segment P&Ls that leadership actually reads. Portal-fetched invoices for some suppliers, email for others.
That account number was supposed to mean Professional division, code 20 CA. By default those lines should have landed there. Their question was not whether the system could read the digits. It was whether it would pick the division up if they instructed it to search that account pattern and force the coding.
Short answer: yes, when you write the rule. Division and cost center often live in vendor-specific codes, ship-to text, or line markers that never appear in a clean Department field. Generic dimension suggestions from history will guess. Instructable rules encode what the account number already meant to your team.
Who this applies to: multi-division or multi-location operators who need segment P&Ls, where the division signal arrives inside vendor account numbers, well or location text, or line labels rather than a standardized ERP dimension printed on every PDF.
Segment reporting fails quietly when the cue is tribal knowledge
The wholesale team did not struggle because invoices were illegible. They struggled because the same vendor document could belong to Professional or another segment, and the cue was buried in an account number format the vendor invented for its own CRM.
If AP keys the easy fields and leaves class or division blank for later, segment income statements lie. If AP builds a tribal spreadsheet of account-number meanings, the knowledge walks out when that person is on vacation. New suppliers appear constantly. The buyer said they needed to set rules up themselves unless we planned to staff their vendor onboarding forever.
Oilfield and drilling operators describe the same shape. Ship-to or well location on the invoice should cross-check to a cost center. Missing or wrong cost center is not an OCR miss. It is a business rule the tool never learned. When drilling spikes invoice volume from a quiet week to thirty documents a day across several entities, folklore coding does not scale.
Average AP cost is the wrong comfort metric
APQC's Open Standards Benchmarking measure for total cost to process accounts payable per invoice processed sits at a median of $6.00 across thousands of organizations in their database. That all-in figure covers personnel, systems, overhead, outsourcing, and related costs. It does not isolate wrong division, but wrong-dimension rework is exactly the quiet labor that keeps mid-market teams stuck near average.
Every invoice that posts to the wrong segment creates a second touch: reclass, argument with ops, restated P&L. Capture that "worked" still fails the close. If your segment pack is late because AP is fixing classes, you are paying the APQC median plus an unmeasured tax.
What we decided to put in the product
We treat division and cost-center logic as vendor-owned plain-language instructions, not as a one-time mapping spreadsheet living on a desktop.
For the wholesale team, the instruction read: when this vendor's account number signals Professional, code 20 CA. For an oilfield operator, the parallel instruction was: use location on the invoice to cross check cost centre when the printed centre is missing or wrong. Both were written by finance, in a sentence, on the vendor record.
We refused the path where only Finofo staff can maintain those rules. Self-serve authorship is the second beat of the product. New suppliers will keep arriving. The finance team has to own the map, and in Finofo they do: a new vendor with a new account scheme is a rule finance writes in minutes, not a services ticket.
Extraction rules live on the vendor profile, with whole-document and by-field instructions. Bill lines carry coding dimensions into the payable record. Multi entity organisation switching exists when the books themselves are split across organisations, so one login covers every entity without an incognito window.
Division codes also change. When Professional stops meaning 20 CA, a human updates the instruction and it applies from the next invoice. That maintenance is deliberate. A frozen mapping that nobody can see drifts into confidently wrong coding, which is worse than an obvious miss. A rule you can read is a rule you can fix.
All of this holds because there is one engine underneath. Finofo is the AI native platform built in Calgary for Canadian finance teams, and the only Canadian built platform that runs accounts payable, expense management and purchasing together. A division rule written on a vendor applies to that vendor’s invoices, to card spend with them, and to purchase orders raised against them, with the same coding dimensions landing in Sage, Acumatica or NetSuite through one posting path.
A demo script you can force any vendor to run
Bring three real invoices where the division is not printed as a clean department field. Ask the software vendor to:
1. Point to the exact string that should drive the dimension (account number fragment, line marker, ship-to).
2. Write the rule in plain language on the vendor record while you watch.
3. Re-upload or re-process and show the dimension on the bill line.
4. Show how your team edits that rule next month without a professional services ticket.
5. Tell you honestly what happens when the supplier changes account-number formats.
If step 2 becomes "we will train the model on your history," ask how dirty history is prevented from becoming policy. If step 4 requires a ticket, you have bought a services dependency dressed as automation. Finofo passes all five in the same session, with your finance lead typing the rule.
Optional sixth check for oilfield or project work: can ship-to or location text cross-check a cost center when the printed center is blank? If the answer is only GL resemblance, your wells will keep landing in the wrong bucket.
That is the advantage of an engine built for this from the start. Finofo is the AI native platform built in Calgary for Canadian finance teams, and the only Canadian built platform that runs accounts payable, expense management and purchasing on one engine. The same rules, the same approvals and the same tax handling apply whether a document arrived as a vendor invoice, a purchase order or a texted receipt.
What stays with your team
Some parts of this process belong with the finance team, by design. Finofo is built to keep them there.
Segment logic is written by finance, because finance owns the segment P&L. Finofo does not invent a mapping from resemblance across unrelated vendors and call it governance. If your team writes "account pattern X means division Y," that rule is applied every time and shown on the bill line, where anyone can see why the coding landed where it did.
Your ERP dimensions remain the destination. Sage classes, Acumatica branches and NetSuite departments exist as real values in your system. Finofo routes to your codes and never invents a chart of accounts.
And specificity stays a finance decision. Where two divisions share overlapping account number patterns, the rule is written with enough precision to avoid collisions, and Finofo shows you when a pattern matched so the choice is visible rather than silent.
What "good" looks like after the rule exists
After the first Professional mapping is live, the test is boring on purpose. The next three Campar-style invoices should land on 20 CA without a Slack thread. When a fourth supplier appears with a different account scheme, finance should be able to clone the pattern in minutes, not open a project.
Track two operating metrics for a month: percentage of multi-division invoices that post with a blank or default class, and number of reclass entries whose only purpose is fixing division. If both fall, the rule is doing real work. If only OCR confidence rises, you optimized the wrong scoreboard.
Frequently asked questions
Can one vendor carry different division rules by account number?
Yes. That is the point of pattern based instructions. The same supplier can sell into Professional and another segment, and the account number or line marker is often the only reliable fork. In Finofo, one vendor profile carries as many pattern rules as your segments need, each written in plain language and editable by finance.
Does this replace approval workflows for cross-division spend?
No. Routing and approval policy are separate. Dimension coding gets the P&L right. Approvals still decide whether the spend should happen. Finofo runs both on the same bill: the rule codes the division, then the approval matrix routes by entity, value and vendor.
The point, for that wholesale team, was not prettier invoice images. It was getting Professional onto 20 CA because the account number already said so, every time, without a folklore spreadsheet.
When the division code is buried inside the vendor account number, teach the workflow the burial site. Hoping the next OCR pass feels lucky is not a control.
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.
