Invoices and documents: AI extraction with human review

Invoice and document automation takes the PDFs and scans that arrive by email or upload, extracts the fields a person would otherwise type, checks them against rules, and hands them to the accountant for confirmation before anything is posted to accounting or an ERP. It is for companies where someone spends part of every week retyping supplier invoices and delivery notes, and where mistakes surface weeks later in the books.

Key takeaways

• Intake comes first: one place where every document lands, with its source and time recorded.
• Extraction produces proposed values with a confidence per field, not final data.
• Validation rules catch most errors before a person sees the document.
• The accountant confirms; the system posts only after that, and every value and change is kept in an audit trail.
• Most errors come from poor scans, unusual layouts and ambiguous fields; review is designed around those.

Step one: intake

Documents arrive as PDF attachments to a shared mailbox, as scans or phone photos, as downloads from a supplier portal. Intake collects all of them into a single queue.

Each document is stored as received, unchanged, with its source (mailbox, upload, person), its timestamp and a unique identifier. An email with three attachments becomes three linked documents; a document that is not an invoice is still stored and classified, so nothing is lost.

This step is deterministic and should work before any AI is involved.

Step two: extraction

The model reads each document and proposes values for a fixed set of fields. For EU invoices, the required content is set out in the VAT Directive (Directive 2006/112/EC, Article 226, https://eur-lex.europa.eu/eli/dir/2006/112/oj); the fields follow from it and from your accounting software: supplier name and VAT number, invoice number, dates, currency, net and VAT amounts per rate, gross total, payment reference, and the account or cost center you assign.

Two design choices matter here.

Every field comes with a confidence. The model says how sure it is, and the system records where on the page the value was read. A low confidence or a missing value marks the field for attention, so the reviewer knows where to look.

Scans are treated differently from digital PDFs. A digital PDF carries its text; a scan or a photo must be read optically first, so image quality decides extraction quality. Blurred, skewed or cropped documents are flagged at intake and, where possible, requested again.

For other document types (delivery notes, order confirmations, contracts), the field set is defined in discovery with the people who process them; the mechanics are the same.

Step three: validation rules

Before a person sees the document, the system checks the extracted values against plain, deterministic rules; the model is not asked to judge them.

• Arithmetic. Net plus VAT equals gross, per rate and in total; line items sum to the net amount where extracted.
• VAT. The rate is one your country allows; the supplier's VAT number has a valid format and, optionally, is checked against the European Commission's VIES service at https://ec.europa.eu/taxation_customs/vies/.
• Duplicates. The same supplier and invoice number, or the same amount and date, already exist.
• Known supplier. The supplier matches your master data; a new supplier is flagged for a person to confirm, including bank details.
• Expected values. The amount is in the range usually seen from that supplier; the due date follows the issue date; the currency is one you trade in.
• Purchase order match. Where you use purchase orders, the invoice references one and the amounts correspond.

A document that passes every rule with high confidence is marked ready; one that fails a rule or has a low-confidence field is marked with the specific problem, and the queue puts problems first.

Step four: the accountant confirms

The review screen shows the original document beside the extracted fields, each highlighted where it was read, with low-confidence fields and failed rules marked. The accountant, or whoever approves invoices, can correct any field, change the account assignment, add a note, or reject with a reason.

Confirmation is the human approval step, and it stays with a person: posting a wrong amount or paying a wrong bank account is cheap to prevent and expensive to undo. Where the person who ordered must also confirm receipt, that approval is an earlier step in the same queue.

Step five: posting to accounting or ERP

After confirmation, the system creates the entry in the accounting software or ERP through its API or import format, attaches the original document, and records the result. Without an API, an export file is produced in the format the accountant already imports.

Posting is deterministic and logged; if the target system rejects an entry, the document returns to the queue with the rejection message.

The audit trail

Every step writes to the audit trail: the original file and its hash, when and from where it arrived, every extracted value with its confidence and page location, every rule result, every change and who made it, the confirmation, and the posting result with the target system's identifier, readable by the accountant and exportable for an auditor.

This makes the automation defensible: months later, the company can show the document, what the system read, what was corrected and when it was posted. Retention periods for accounting documents are set by national law; apply yours to the originals and the trail together.

Where errors come from, and how review catches them

• Poor scans. Blur, skew, low contrast. Caught by image quality checks at intake and by low confidence on the affected fields.
• Unusual layouts. A supplier whose invoice puts the total at the top or splits VAT unusually. Caught by arithmetic checks and confidence; the reviewer fixes it once and the layout is known.
• Ambiguous fields. Several dates on a page, several numbers that could be the invoice number. Caught by rules (due date after issue date, invoice number format) and by showing where the value was read.
• The wrong document. A proforma, a reminder or a quote read as an invoice. Caught by classification at intake and by the duplicate check against the real invoice.
• Master data changes. A new supplier, a changed bank account, a new VAT rate. Caught by the known-supplier and expected-value rules and always confirmed by a person; a changed bank account is verified by calling the supplier on a known number.

The reviewer's time goes to these cases; documents that pass every check get a short look.

How we do it at Hot Skulls Labs

Document automation is the same pattern as every automation we build: a trigger (a document arrives), an AI draft (the extracted fields), human approval (the accountant confirms) and execution (the posting). The pattern comes from our own product, Strady, and we apply it to a client's mailbox, scanner and accounting system.

In practice:

• Discovery is done with the person who processes documents today and with your accountant; they define the fields, the rules and the target system.
• We build intake and the audit trail first; extraction and rules are added on top and tested against your own past documents before going live. Rules are written in plain language before they are coded.
• Confirmation stays with a person. We do not offer automatic posting at launch.
• We connect to the accounting software or ERP you use, through its API or import format.
• Documents and extracted data are stored in the EU, with retention aligned to your accounting obligations; the AI provider receives the document, not your ledger.
• We run and adjust the system after launch, adding supplier-specific handling as unusual layouts appear.