When payables codes an invoice, it is answering a question that somebody else already knew the answer to weeks earlier: what was this for, and whose budget carries it. By the time the invoice arrives that knowledge has to be reconstructed from a supplier name and a description, which is why coding is both slow and inconsistent in most organisations.
Why it is hard at the invoice
The account is not printed on the document, because it is a fact about your organisation rather than about the transaction the supplier sees. The same supplier can bill for things belonging in different accounts and different cost centres. Payables is therefore inferring from a name and a description, which is guesswork dressed as processing.
Coding at the order instead
When a purchase is requested, the requester knows what it is for and which budget carries it. Capturing the coding then, and letting the invoice inherit it through the match, removes the reconstruction entirely. It also improves accuracy, because the person answering actually knows, and it makes the budget position visible at the moment the commitment is made.
What to do about the residue
Invoices with no order still need coding, and software can suggest from the supplier and from history. Treat suggestions as suggestions: accepting them unexamined propagates last year's mistakes indefinitely. And keep the chart of accounts small enough that two people would code the same invoice the same way.
Questions people ask about coding invoices accounts payable
Should payables or the requester code?
The requester, at the point of purchase, wherever a purchase order exists. Payables coding after the fact is reconstruction.
Can coding be automated?
Suggested reliably for repetitive spend, decided reliably only where the supplier always means the same thing. Treat it as assistance.
What if we code something wrongly?
It is corrected through your accounting process. How and when is a question for your accountant rather than for payables.