Posting invoices automatically: from document to reliable posting

What does posting invoices automatically mean?

In its simplest form, software extracts details such as supplier, invoice date, amount and VAT from a document. That is recognition. Posting goes a step further: the software determines the right administration, contact, GL account, VAT code, payment condition and, where applicable, cost centre or project. A proposed posting is then prepared or sent straight to the accounting package.

The difference matters. Reading a field correctly does not yet mean the accounting treatment is right. An invoice may have a single total, for example, but contain lines for materials at 21% VAT and labour to which a different treatment applies. Recognising only the total simply moves the work to the reviewer. Reliable automation therefore has to understand both the document and the accounting context.

The five parts of a workable posting flow

1. Submission without detours

Invoices arrive by email, through an upload, a mobile app or as an e-invoice. A good flow keeps those routes clear and prevents staff from having to download, rename or drag documents into different folders first. Structured e-invoice formats such as UBL deserve a separate path: there the invoice details are already data inside the file, so image recognition is not needed. With a supplier, watch the distinction between recognising such a format and being connected to a sending network. Those are two different things. In both cases the software has to check whether the data is internally consistent and belongs to the right administration.

2. Recognition of both header and lines

Header details include the invoice number, date, supplier and total. For many standard invoices that is enough to follow an existing posting pattern. For exceptions, line-level recognition is needed. Think of an invoice that lists products, packaging, transport and deposits separately, or that carries several VAT rates. Line recognition makes it possible to link each part to the right GL account and VAT code.

3. Context from firm, administration and supplier

The same supplier can be posted differently for two clients. A firm also has its own agreements about rounding, cost centres or the level of detail it wants. That is why one general set of rules is rarely enough. A workable system combines general tax limits with firm agreements, administration settings and knowledge of the contact. Corrections have to stay visible and manageable; otherwise you end up with an opaque collection of automatic decisions.

4. A clear boundary for human review

Fully automatic sounds attractive, but every document flow contains poor scans, missing pages, new suppliers and unusual transactions. The question is not whether a system has doubts, but what it does then. A safe solution parks the document with a concrete reason and shows which fields need attention. Your colleague then does not have to redo everything, but only checks the uncertain parts.

5. Posting and feeding back

After approval, the proposed posting has to land reliably in the accounting package. Check whether the connection only creates a draft or can also post directly, how attachments are sent along, and what happens when the package returns an error. An audit trail should record which data came from the document, which rules were applied and who made a correction. That makes problems explainable and helps with internal quality control.

Why a forty per cent exception rate costs so much time

For a current scan & recognise flow we assume sixty per cent automation, and therefore forty per cent exceptions. The gain is not only in processing a tidy monthly invoice from a known supplier even faster. The time is mostly lost in the remaining pile: receipts with poor print quality, unknown contacts, composite invoices and documents that lack context. That is exactly where several actions are needed: reading, searching, comparing, splitting and sometimes consulting a colleague.

So do not measure the percentage of recognised documents alone. A supplier can show a high recognition rate while your people correct plenty of fields afterwards. Better to look at the share of documents posted correctly without any correction, the average handling time for exceptions, and the number of errors only discovered later in the period. Those figures say more about the real saving.

Which risks should you test beforehand?

• Posting on silently when in doubt. Ask how uncertainty is measured and whether you can set the threshold per administration.
• Wrong generalisation. A correction for client A must not automatically become an incorrect rule for client B.
• Unclear data location. Ask separately about hosting, storage, AI processing, retention periods and optional features.
• Invisible exceptions. Connection errors have to show up in a work queue and must never let documents disappear.
• A pricing model that punishes peak months. Calculate with the real spread of documents across administrations and months.

Tandem or full replacement?

A switch does not have to be all or nothing. You can first put a new solution alongside your existing scan & recognise software for the difficult documents. That keeps the trial focused: select representative exceptions and compare the outcome with your current way of working. Watch handling time, corrections, the explanation given in case of doubt, and the quality of the final posting.

Full replacement makes sense when the new solution also covers the standard flow, the connection, control and support convincingly. Include more than licence costs in the comparison: implementation time, duplicated work during the transition and the cost of an incorrect posting count too. Starting with a focused side flow gathers evidence in your own administration before a broad migration is needed. For a concrete application, also read our page about an alternative to Exact Scan & Recognise.

Setting up a trial that really proves something

Do not pick the nicest invoices only. Build a set with different suppliers, scans, receipts, VAT situations and administrations. Record in advance what “correct” means and who assesses the outcomes. A small trial with fifty representative documents often gives more insight than hundreds of standard documents.

1. Select ten tidy standard invoices as a baseline check.
2. Add twenty documents that currently need manual splitting or looking things up.
3. Include ten poor scans, receipts or unknown suppliers.
4. Test ten documents with administration-specific or contact-specific agreements.
5. Measure processing time, corrections, types of error and the clarity of the review screen.

Look at how the system learns from corrections as well. An improvement after repeated documents is useful, but only if you can see which rule was created and where it applies. Ask too what happens when a supplier changes its invoice layout. A system that leans too heavily on position can then quietly get worse.

Assessing privacy and data processing

Invoices contain personal data, bank details and commercial information. A data processing agreement therefore has to state not only where the web app runs, but also which parties process document content. Distinguish between hosting and storage, regular AI processing and optional features such as voice support. Check retention periods, encryption, access control, logging and the procedure for deletion or export.

Ask explicitly whether documents are used to train general models. The answer should be separate from the question of whether temporary processing or logging is needed for the service. “No training” does not automatically mean “nothing retained”. A supplier that keeps these concepts clearly apart makes a careful assessment easier.

Building the business case

First work out how much time your people currently spend on entry, correction and resolving exceptions. Do not simply multiply that by an internal hourly rate; look at peak loads and postponed client work as well. Set the software costs, implementation, review and remaining exceptions against it. A realistic business case does not assume one hundred per cent automation.

With prices, watch for firm minimums, tiers, document bundles, costs for extra users and any surcharges above the included usage. A low amount per administration can work out differently for a small firm because of a monthly minimum. That should be transparent before the trial even starts. Agentancy's current rates, including minimums, are on our pricing page.

Checklist for a supplier meeting

• Which documents are processed at line level and which only at total level?
• How does the system show doubt, and who decides when human review is needed?
• Can rules apply separately for the firm, the administration and the supplier?
• What is posted directly and what stays a draft?
• Where are hosting and storage located, and through which region does the AI processing run?
• Are our documents used to train models?
• Which monthly minimums, tiers and usage limits apply after the trial?
• Can we start with the difficult documents only?
• How do we export data and learned rules if we stop?

Conclusion

Posting invoices automatically is not a stand-alone recognition feature, but a chain of submitting, understanding, reviewing, posting and feeding back. The best solution is not the one that says “automatic” most often, but the one that demonstrably leaves less manual work without introducing invisible risks. So test with the difficult documents from your own practice, and make the boundary for human review part of your assessment.

Want to see how Agentancy puts this approach into practice? Take a look at posting invoices automatically with Agentancy, try a tricky receipt in the demo or get in touch for a trial with your own set of documents.