How to code accounts payable invoices to the general ledger with an LLM

The pain points

The chart of accounts is yours. A model knows what "software" is. It does not know that your subscriptions go to one account, implementation services to another, and anything over your capitalization threshold to the balance sheet.

Same vendor, different accounts. One supplier sends a subscription renewal, a training invoice and a hardware order in the same month. Vendor-to-account lookups get most of them and fail on exactly the lines that need judgment.

Your history is inconsistent. Different clerks coded the same kind of line differently, and a mid-year chart restructure changed what "correct" means.

Not all mistakes are equal. Two neighbouring expense accounts is an annoyance. Expense versus asset changes the P&L, and someone will find it at close.

The long tail. A handful of accounts cover most lines. The rest appear a few times a year, and that is where the errors live.

How to do it

Train on posted, approved entries, with the chart as it stood on the posting date. Coding that a reviewer corrected is the label; the original clerk's guess is not.
Give the prompt the relevant slice of the chart, not all of it. A lookup step can fetch this vendor's recent coding and the handful of candidate accounts for the line's category, frozen onto each row. The prompt then chooses among a short list, with definitions, rather than recalling the whole chart.
Score at two levels. Exact match on the account, and match on the account group (expense versus asset versus liability) as a second metric. Weight the second heavily. A prompt that is often off by one expense line but never crosses the balance sheet is one your controller can live with.
Hold out by time. Keep the most recent months out of the search, so the score says how the prompt does on invoices it has not seen, under the chart as it is now.
Route what the prompt is unsure of. Ask for the account and a short reason, send low-agreement lines to a person, and record their corrections. Those become the next dataset.

Pitfalls worth checking first

Pitfall	What it looks like	How to check, before spending anything
Chart changes	Old rows coded to accounts that no longer exist	Map or drop rows from before a restructure.
Leakage	Approver comments or posting batch predict the account	Keep only what exists when the invoice arrives: the invoice, the PO, the vendor record.
Vendor memorization	Great on known vendors, poor on new ones	Hold some vendors out entirely and score them separately.
Flat accuracy	Frequent accounts dominate the score	Read the per-account table; score the account group as well as the account.
Line versus invoice	One invoice, three correct accounts	Label and score per line, not per invoice.

How to code invoices to the general ledger

The pain points

How to do it

Pitfalls worth checking first

References