How to automate GL coding in accounts payable: four options compared

If every supplier sold one thing to one team, GL coding would be a lookup table. In practice:

• Suppliers sell more than one thing. One IT reseller sends software renewals, laptops and two days of on-site installation. Those can be three different accounts.
• The same purchase can be coded differently for different teams. Software for the sales team and software for engineering may land in the same account but different cost centers, or in different accounts if R&D is tracked separately.
• Descriptions are messy. "Annual renewal – see attached", "EDR 500 seats", a PO number and nothing else.
• The answer has several parts that have to fit together. A GL account, a cost center and a tax code that are each plausible on their own can still be a combination your team never uses.

The knowledge to get it right usually exists: it's in your ledger, in every line your team has already coded and approved. The question is how much of it each option can use.

Most accounting systems and AP tools let you write rules: if the supplier is X and the description contains "license", code it to 6410. Some call them coding rules, posting rules or memorized transactions.

Good at: a small number of fixed, high-volume cases. Rules are transparent: anyone can read why a line was coded the way it was. They cost nothing extra if your system has them.

Where they break:

• Every exception needs another rule, and rules collide. "Software license audit services" matches both a software rule and a consulting rule, and whichever runs first wins.
• Nobody owns them after a year. Rules written for last year's chart of accounts keep firing after a restructure.
• They can't say how sure they are. A rule either matches or it doesn't, so there's no natural way to send the doubtful lines to a person.

Many systems let you set a default expense account on the supplier record. QuickBooks Online, for example, lets you set a default category on a vendor's profile, and new transactions for that vendor then show it automatically. NetSuite and other ERPs have a similar default expense account on the vendor.

Good at: single-purpose suppliers: the electricity company, the office cleaner, the payroll provider. It takes minutes to set up and covers a lot of lines.

Where it breaks:

• Multi-purpose suppliers. The default is right for one kind of purchase and quietly wrong for the rest, and a filled-in default looks just like a decision someone made.
• Cost centers and departments. A vendor default usually covers the account, not who the purchase was for.

Vendor defaults are worth having for the suppliers where they're always right. Just don't count those lines as "automated" when you measure the rest.

AP automation tools capture invoices (reading PDFs and emails), route them for approval and sync them to the ERP. Many now suggest GL coding too. Stampli, for example, describes its AP assistant as auto-coding invoices to GL accounts, with finance staff validating or overriding the suggestions, and learning when people adjust them.

Good at: the whole invoice journey in one place: capture, coding, approval and posting. If you're also replacing a manual approval process, a suite is often the right purchase.

Where to look closely:

• What it learns from. Does it learn from your existing coded history, or only from corrections made after you start? Ask the vendor.
• Whether you can see how well it codes. Ask for accuracy on your own lines, by account, before go-live, not a general figure.
• The cost of switching. A suite replaces your current capture and approval process. That's a bigger project than improving the coding step alone.

The fourth option skips writing rules altogether. You export lines your team has already coded and approved, train a model on them, and it suggests the account and cost center for new lines the same way, with a confidence on each one.

Good at:

• Multi-purpose suppliers and messy descriptions. It learns from the description, the supplier, the requesting department and anything else in the line, including the exceptions your team made.
• Several fields at once. It can learn the GL account and cost center together, so the two always form a combination your team actually uses.
• Knowing what it doesn't know. Lines below a confidence cutoff go to a person; confident lines go through.
• Keeping your existing tools. It sits between capture and posting. Your AP tool or ERP stays as it is.

Where it breaks:

• It needs history. A few hundred coded lines is a start, with more for accounts that look alike. Brand-new accounts have no examples until your team codes some.
• It only knows what it was trained on. After a chart-of-accounts change, retrain, or new accounts won't be suggested.
• It doesn't read PDFs or post to the ledger. It codes lines that have already been extracted, and your reviewers and ERP stay in charge of what's posted.

For a step-by-step walkthrough of this option, see AI invoice coding: GL accounts and cost centers.

A common combination: vendor defaults for single-purpose suppliers, a model for everything else, and a person for the lines the model isn't sure about.

Whichever option you choose, test it on lines your team has already coded, and that the system hasn't seen. Then look at:

• Accuracy by account, not just overall. "94% of lines right" can hide an account that's wrong half the time.
• Money in the right place. Add up the amount on correctly coded lines and divide by the total. If that's lower than line accuracy, the large lines are the ones going wrong.
• What the review cutoff catches. For every 100 lines, how many go to a person, and how many of the mistakes are among them?
• Rare accounts. Capital expenditure, intercompany and anything with tax consequences deserve a stricter cutoff or a person every time. Agree that with your controller.

StayCharted AI Model Trainer is option 4, without code and without changing your AP process.

• Train on your coded lines. Upload an export (Excel, CSV or JSON) with the description, supplier and any other columns you'd use, and the account your team approved. Choose several answer columns, such as GL account and cost center, and the model learns them together. It answers only with combinations your team has used.
• Checks before training. It finds duplicate lines, the same description coded two ways, accounts with too few examples to test, and personal information such as emails and phone numbers, which you can mask before training. Bank details have no place in a coding model.
• A test you can read. Every model is tested on lines it never trained on, with results per answer and the ones it confuses, before anyone relies on it.
• Code new lines where you work:
  • fill a file: you get the same file back with the answer columns and a confidence added, and every other column unchanged;
  • fill rows in Google Sheets with the add-on;
  • call the API (Essentials and Business), so lines are coded as they arrive.
• People review the unsure lines. On Essentials and Business, lines below your cutoff wait in the Review Queue. A reviewer confirms or corrects each one, and the corrections train the next version.

Your examples train only your workspace's models. StayCharted doesn't post anything to your ledger.

Start free → · Not ready with your own export? On Start here, choose Expenses and invoices to try a sample of 100 expense lines first. · Compare plans → · Security and your data →