From Supplier Invoice to Bookkeeping: AI with a Control Checkpoint
By Greg Nowak. Last updated 2026-08-18.
At first glance, a supplier invoice looks like an ideal task for AI. Identify the supplier, invoice number, date, amount and VAT. Suggest an account, then pass the information to the bookkeeping system.
Could your business use this? nowa.dk sets up AI automation for Danish companies.
This can eliminate a significant amount of data entry. But an invoice has not been booked correctly just because the model has produced a neat JSON object.
There should be a control checkpoint between extraction and bookkeeping. At this stage, the system compares the proposed values with the source document, the company’s rules and previously processed invoices. Entries that are reliable, permitted and documented can proceed automatically. Everything else is referred to a person.
New bookkeeping requirements make these controls increasingly relevant
From 1 January 2026, the digital bookkeeping requirement also covers more businesses that do not prepare annual reports under the Danish Financial Statements Act. According to the Danish Business Authority’s guidance on the Bookkeeping Act, this includes businesses not subject to financial reporting requirements if their net revenue has exceeded 300,000 kroner in two consecutive income years. For existing sole proprietorships, 2024 and 2025 may therefore be the decisive years.
The Danish Tax Agency’s bookkeeping guidance also makes clear that the business retains ultimate responsibility for accurate bookkeeping, even when a bookkeeper performs the work. The same division of responsibilities applies to AI: the technology can read, suggest and check, but responsibility does not transfer to the model.
It is therefore too narrow to measure automation solely by speed. A workable process must also preserve the link between the invoice, the extracted information, the approval and the entry that ultimately appears in the accounts.
A correctly formatted output can still contain the wrong amount
An LLM API can convert a PDF, image or OCR text into predefined fields. With Structured Outputs, the response can be constrained to an agreed JSON schema. For example, it may require the supplier name, CVR number (Danish company registration number), invoice number, invoice date, due date, net amount, VAT, total and currency.
This makes integration considerably easier. The application knows which fields to expect and whether the values use the correct data types. But the schema cannot prove that the total was read correctly, that the net amount and VAT add up, or that the model selected the invoice date rather than another date shown in the document.
A new benchmark preprint on structured output demonstrates precisely this distinction. The models examined almost always followed the required schema, while the highest accuracy for the field values themselves was 83.0 percent for text and 67.2 percent for images. The study is not specifically about Danish invoice bookkeeping, but it illustrates the problem precisely: a technically valid response can still be factually wrong.
Controls must follow the source document throughout the process
An audit-friendly document workflow can be divided into seven stages. The invoice is received and assigned an internal ID. Text and fields are then extracted using OCR, document logic or an LLM. The output is checked against the schema, and business rules test its contents. Based on these checks, the system calculates the risk and chooses either automatic processing or human approval. Finally, the entry and source document are transferred to the bookkeeping system, and the result is reconciled.
| Control checkpoint | What the system checks | If something does not match |
|---|---|---|
| Document | Can the file be opened, and are all pages included? | Stop the process and request a new source document |
| Fields | Are dates, currency and amounts in a valid format? | Send the document for manual processing |
| Amounts | Does the net amount plus VAT equal the total? | Flag the discrepancy and do not create the entry |
| Supplier | Do the CVR number and payment details match the master data? | Require approval of the change |
| Duplicate | Has the same invoice number, supplier and amount been processed before? | Block the entry or compare the documents |
| Risk | Are the amount and proposed account within the agreed limits? | Send the entry to an approver |
| Post-processing check | Have the API response and source-document reference been saved correctly? | Reprocess without creating a duplicate |
Structure, business rules and approval each serve a different purpose
Schema validation determines whether the output can be processed by an application. Is the invoice date a date? Is the total a number? Are all mandatory fields present? This is a necessary check, but it only establishes whether the structure is correct.
Business validation examines whether the values make sense in the company’s real-world context. Python rules can, among other things, recalculate VAT, compare the total with subtotals, look up the supplier in master data and check whether the proposed account is permitted for that type of supplier. The rules should be visible and version-controlled. Otherwise, it becomes difficult to explain an entry after the rules have changed.
Human approval addresses uncertainty and financial risk. Each company sets its own thresholds. New suppliers, changed bank details, larger amounts, unclear credit notes or uncertain data extraction can always trigger an additional review. This does not diminish the value of automation. It is what makes the process defensible in practice.
Duplicates must be caught both before and during integration
The same invoice may arrive through several channels. An entry may also be submitted again if an API call times out. The solution should therefore generate a stable fingerprint from the invoice’s key information and check whether the document already exists. The supplier, invoice number, date, currency and total are more reliable identifiers than the filename.
e-conomic’s document API supports idempotency keys for write requests. If a request is repeated with the same key within the API’s cache window, the API can return the original result instead of performing the action again. This is useful in the event of network errors, but it is not sufficient on its own. The documentation specifies a cache window of one hour, so the company still needs its own persistent duplicate check.
The API can also attach documents to posted entries. In 2026, its document functionality was expanded to include image formats and a conflict setting that can either merge with an existing document or reject the attachment. The integration should therefore use a tested API version, handle conflicts explicitly and retain the request, response and source-document reference.
The log is not mere technical decoration
The Danish Business Authority describes the audit trail as the information needed to verify the basis for the records, including who performed the bookkeeping. In an AI-supported process, it should therefore be possible to retrieve the original source document, the extracted values, the results of the rules, any corrections, the approver and the final reference in the bookkeeping system.
This does not mean that every technical detail must be retained. The log should make specific questions easy to answer: What came in? Which version of the rules was used? Why was the entry approved, rejected or referred for review? What was actually created?
A subsequent reconciliation should confirm that every accepted source document has resulted in an entry and that the expected document remains attached to it. Otherwise, the company risks having a process that appears complete in the integration layer but is incomplete in the accounts.
Start with the document workflow, not the model
The first task is to map the existing process. Where do the invoices come from? Who approves them today? Which suppliers and accounts recur? And where do errors or delays arise? Once this is clear, the relevant OCR tools, Python components, LLM APIs and integration methods can be selected.
Through nowa.dk, an AI automation service for Danish companies, Greg can map the workflow, build the extraction and validation stages, and connect the process to systems such as e-conomic. A realistic first version can be limited to one document type and a small number of known suppliers. Before expanding it further, the company can measure corrections, duplicates, processing time and the proportion of entries that still require manual review.
The strongest business case is not necessarily fully automated bookkeeping. It may just as readily be less rekeying, faster handling of standard cases and clear safeguards when something does not add up. With a proper control checkpoint, AI becomes a practical part of the document workflow without turning bookkeeping into a black box.
Related on GrN.dk
Need help with this type of work?
Get your document workflow mapped out. Contact Greg here.