Automatic invoice booking means that an incoming invoice is read by software instead of being typed over by hand, so that a journal entry is ready for your accounting package. The reading is automatic; the final decision is not. In this article you can read what happens in each step, and where the human check sits.
Contents
What is automatic invoice booking?
Automatic invoice booking is the process in which software reads an incoming invoice, works out which general ledger account and VAT code belong to it and prepares a journal entry, so that nobody has to retype the invoice into the accounting package. The term is used loosely in the market. Some suppliers mean reading only, others mean posting without any human involvement, which are two very different things in practice.
The distinction matters for your administration. An invoice that is posted without a check still has to be corrected afterwards if the coding was wrong, and a correction costs more time than the check would have.
How does automatic invoice booking work?
The process runs in five steps: the invoice arrives, the data is read, a booking proposal is prepared, someone checks it, and the entry lands in your accounting package. Steps one to three are automatic. Step four is where you stay in control.
1. The invoice arrives
Invoices come in by e-mail, as an upload, from a mobile app or as an e-invoice over the Peppol network. Paper still exists too: a scan or a photograph enters the same queue. What matters is that every channel ends up in one place, otherwise you are chasing invoices in three systems.
2. Reading the data
For a scan or a plain PDF, character recognition combined with self-learning models pulls out the invoice number, the date, the amounts and the VAT rates, down to line level. For a UBL or Peppol invoice that step is not needed, because the data is already structured, following the Peppol standard for electronic invoicing. Note what does not disappear with an e-invoice: the file tells you what the amounts are, not which general ledger account they belong to.
More about that difference in the comparison between PDF and UBL, and about the reading itself in reading invoice data.
3. The booking proposal
From the recognised data a proposal is prepared. It contains:
- the supplier, matched against the creditors in your administration
- the invoice number, the date and the payment term
- the amounts per VAT rate, split when one invoice carries several
- a general ledger account per invoice line
- a cost centre or project, where you work with those
Self-learning models use your earlier entries to predict the coding, so a supplier you book every month needs less and less correction. This is the step that determines the quality of your books, and it is the step that is usually underestimated.
4. Checking and approval
Automatic does not mean unchecked. Someone looks at the proposal with the document next to it and confirms or corrects it. On top of that you can route the invoice past a budget holder or a manager first, through an approval route for invoices, so that authorisation and coding happen in one flow instead of in an e-mail thread.
5. Into the accounts
After the check the journal entry goes to your accounting or ERP package, with the original document attached to it. The payment run happens there, not in the pre-accounting software. What stays behind is an audit trail per document, which is what you need at the year-end or during an audit.
What you gain
- Time. The typing disappears, and with it the queue of invoices waiting to be entered.
- Fewer typing errors. Amounts and numbers are read from the document rather than copied by hand.
- A current set of books. Invoices are processed on the day they arrive, so your outstanding liabilities are up to date.
- Traceability. Who did what and when stays recorded per document.
Where it goes wrong
Three things determine whether automation actually helps:
- Unclear approval rules. If nobody knows who signs off on what, the invoice waits regardless of the software.
- No check on the coding. Recognition improves with use, but only if corrections are actually made instead of confirmed blindly.
- Exceptions treated as failures. Handwritten notes, credit notes and unusual layouts need a person. That is not a defect, it is the remaining ten per cent.
What TriFact365 does, and does not do
TriFact365 does not post invoices on its own, and that is deliberate. The software reads the invoice, prepares the booking proposal with a general ledger account and VAT code per line, and sends the journal entry to your accounting package after your visual check. You decide what gets posted; what disappears is the typing. Read how that runs from receipt to journal entry, or see which packages connect to your bookkeeping.
Frequently asked questions
No. In most software, including TriFact365, the reading and the coding are automatic while the confirmation stays with a person. Posting entirely without a check is technically possible but shifts the work to corrections afterwards, which usually costs more time than the check itself.
No. A UBL or Peppol invoice removes the character recognition, because the data is already structured. It does not decide which general ledger account, VAT code or cost centre the lines belong to, and that is the part that determines the entry.
Field recognition above ninety per cent is realistic on invoices with a normal layout, and it improves per supplier because the models learn from your earlier entries. Handwriting, poor photographs and unusual layouts remain the exception that needs a person.
Purchase invoices are the core, and sales invoices and receipts run through the same flow. Delivery of the document can be by e-mail, upload, mobile app or Peppol, and everything ends up in one queue.
You need a connection between the pre-accounting software and your accounting or ERP package, because the journal entry has to land there. TriFact365 connects to the commonly used packages in the Netherlands and Belgium; the payment run always stays in your own package.
