Code vendor invoices to the right general ledger account
For non-PO invoices, a model proposes the GL account, department and cost center from the vendor, the line description and how similar invoices were coded before. Rules apply your coding policy first, and an approver confirms low-confidence picks. Fits teams where coding is the slowest step in accounts payable.
Function: Finance · Industry: Any industry
Code vendor invoices to the right general ledger account
6 steps
At a glance
- Trigger
- A non-PO vendor invoice has been captured and read.
- Typical inputs
- Invoice lines and vendor master
- Chart of accounts and coding policy
- Past coded invoices for the same vendor
- Approver map by department
- Systems it usually connects to
- QuickBooks
- Xero
- NetSuite
- Slack
- How the work splits
4 rules, 1 model, 1 person steps
How it runs, step by step
6 steps, each tagged by what does the work. Rules are fixed logic, a model reads or drafts, and a person decides.
- Rules Fixed logic in code
- Model AI reads or drafts, with a confidence score
- Person A named person decides
- 1
Apply fixed coding rules
RulesVendors with a single standing account, such as a utility or software subscription, are coded by lookup without any model involved.
- 2
Propose coding for the rest
ModelA model reads the line description and past coding for similar lines, then proposes an account, department and class with a confidence score.
- 3
Check the policy
RulesCode blocks accounts that need a PO, capital items above your threshold and any account closed to AP.
- 4
Confirm low-confidence picks
PersonLines below your confidence bar go to the budget owner or an accountant, who accepts or changes the coding in one click.
- 5
Route for approval
RulesThe coded invoice goes to the approver for that cost center, with the reasoning shown beside each line.
- 6
Learn from corrections
RulesEvery change a person makes is stored as a labeled example so the next proposal for that vendor is better.
Where people approve
The decisions that stay with your team, whatever the confidence score says.
- Budget owners approve coding for their cost center.
- An accountant signs off on any capital or prepaid classification.
- New vendors need their first invoice coded by a person.
KPIs to track
What to measure, before and after. Targets come from your own baseline.
- 01Share of lines coded without a correction
- 02Time from invoice receipt to coded
- 03Recodes found at month-end close
- 04Invoices waiting on an approver, by age
Questions about this workflow
How does it avoid miscoding something sensitive?
Rules run first. Accounts such as legal fees, related-party payments or capital items can be set to always require a person, no matter how confident the model is. The model only suggests within the accounts you allow for that vendor.
Will it work with a messy chart of accounts?
It copes with a large one better than with an inconsistent one. If two accounts mean the same thing, the audit usually recommends cleaning that up first, because otherwise corrections pull the suggestions in two directions.
Which steps use rules, a model and a person?
Rules: apply fixed coding rules; check the policy; route for approval; learn from corrections. Model: propose coding for the rest. Person: confirm low-confidence picks. Rules are fixed logic in code. A model reads or drafts and reports its confidence. A named person decides.
What do we need to start?
Typically: invoice lines and vendor master; chart of accounts and coding policy; past coded invoices for the same vendor; approver map by department. You also need read access to QuickBooks, Xero, NetSuite and Slack, or the equivalents you use. A workflow audit measures your volumes and past cases first, then gives a fixed price for the build, so you can decide with real numbers.