Supplier invoice posting
Each supplier invoice matched line by line against the purchase order and the delivery note, with differences flagged and the posting prepared for approval
For companies that post supplier invoices without being able to match them line by line against the purchase order and the delivery note.
- Data sources
- Email or supplier portal · ERP (the company's management system)
- Email or supplier portal
- ERP (the company's management system)
- Approval
- Finance approves, changes or rejects the proposed posting; Purchasing is notified of price differences
- First step
- A test run on last financial year's invoices, before any new posting is proposed
Supplier invoice posting
In preparationPending approval- Invoice data extracted
- Price difference from the agreed price
- Quantities matching the delivery note
- Posting prepared with the price difference flagged
Supplier invoice posting is the process in which the agent (the software that carries out the work) matches every invoice received against the purchase order and the delivery note recorded in the ERP (the company's management system), flags differences in quantity and price, and prepares the proposed posting with the ledger account, cost centre and expense type.
Finance approves, changes or rejects the proposed posting; Purchasing is notified of any price difference.
On this page
The manual process
Supplier invoices arrive by email or through a portal, in different formats and often with dozens of lines. The manual process involves locating the purchase order, comparing the invoice with the delivery note, checking prices against the terms agreed with the supplier and keying in the posting with its ledger account and cost centre.
The work piles up at the month‑end close, and the most valuable check, that every invoiced line corresponds to goods ordered and received, is the one performed least often.
Without line‑by‑line matching, the company pays prices that differ from those agreed, pays for more than it received and pays duplicate invoices, and notices these errors late or not at all. Manual matching depends on ERP exports pasted into spreadsheets whose layout changes from month to month.
Data sources and the company map
The company map is the written description of where each piece of data is held, what each source contains and how each situation is analysed. The agent performs each task according to the map and does nothing beyond what the map defines.
Show the figure
Map contents for this use case
Show details
For this use case, the map sets out two sources: the invoice mailbox or supplier portal, which supplies the invoice in its original file, and the ERP, which supplies the purchase orders, delivery notes, the terms agreed with each supplier and the accounting reference lists for expense families and cost centres. Using those two sources, the map defines four checks and two operations subject to approval.
The agent reads both sources and writes nothing to them except the two operations Finance approves. Every figure in the proposal carries the date of its last update; if a source does not respond, the figures from that source are marked as out of date and the invoice still goes ahead. The only two operations in the use case, recording the invoice as checked and posting it, take place only with Finance's approval.
Reading the invoice from the original file
The agent reads the invoice from the file the supplier sent (PDF, spreadsheet or electronic invoice) using the reader built for that format. No line is summarised: every line is captured with its text, quantity and price, and charges such as carriage, discounts and taxes are captured as separate lines.
The first invoice in a new format is read by a language model (the artificial‑intelligence program that reads text), and that invoice is held as an outstanding query until a reader for the new format has been tested. Known formats are read without a language model.
Matching each line against the purchase order and the delivery note
The agent matches every invoice line to the corresponding purchase order and delivery note lines by reference, not by amount: an identical amount does not identify a line.
Show the figure
Every line, matched by references in sequence
Invoice line
- Purchase order reference quoted
- Delivery note number
- Item reference and date
ERP
- Purchase order lines
- Delivery note lines
- Items and receipt dates
- Line matched to its purchase order and delivery note lines
- No match: sent to Purchasing as a line without a purchase order, with its original text
Show details
The agent tries the references in turn, falling back to the next only when the previous one is missing: the purchase order reference quoted on the invoice; failing that, the delivery note number; failing that, the item reference and the date. All three references are held in the ERP.
A line with no match is not discarded: the agent classifies it as a line without a purchase order, with its original text, and sends it to Purchasing.
Comparing quantities and prices
Once a line is matched, the agent makes two comparisons: invoiced quantity against the quantity received on the delivery note, and invoiced price against the price agreed in the supplier's terms. Each comparison records a result on the line: a match, or a difference with its reason.
A price or quantity difference, or a line with no match, does not stop the invoice: the invoice goes for approval in full, with the result recorded on every line. A duplicate invoice is the exception: it reaches Finance without a proposed posting.
Show the figure
| Difference | Detection | Recipient |
|---|---|---|
| Price different from the agreed price | Line price against the supplier's terms | Purchasing, which agreed the terms |
| Quantity exceeding the quantity received | Line quantity against the delivery note | The person who recorded the delivery note |
| Line without a purchase order | No match in the reference sequence | Purchasing: a purchase without an order, or a supplier error |
| Duplicate invoice | Same supplier and same invoice number, or same lines under a different number | Finance; the agent does not propose it for posting |
Proposing the posting
The proposed posting is the accounting entry (the record of the invoice in the company's books) that the agent prepares for every matched invoice.
Show the figure
The proposed posting, field by field
Proposing the posting
Pending approval · Finance| Field | Source | If unresolved |
|---|---|---|
| Ledger account | Formula applied to the expense family and purchase type | The expense family's account, flagged as an outstanding query |
| Cost centre | Cost centre reference list, by purchase order or by the line's destination | The purchase order's cost centre, if it has one; otherwise blank |
| Expense type | Formula applied to the purchase type, supplier and line text | Blank; no default value |
Show details
The proposed posting is built on two fields already held in the ERP: the purchase type, which the purchase order assigns to each item ordered, and the expense family, the expense group the ERP uses to classify each item.
For each group of lines, the agent determines three fields of the entry: the ledger account, the cost centre and the expense type, which is the accounting classification of what was bought. All three come from the ERP reference lists and from the formula. The formula is the posting rule agreed once with Finance during rollout; the formula assigns each group of lines a ledger account, from the expense family and purchase type, and an expense type, from the purchase type, supplier and line text, and the cost centre comes from the ERP's cost centre reference list.
A formula with a few inputs and two reference lists (expense families and cost centres) replaces a case‑by‑case list of accounting rules: every rule on such a list is one output of the formula.
A field the formula cannot resolve (a new supplier, a charge with no expense family) arrives with the fallback value flagged as an outstanding query or, where there is no fallback, blank; never with an unflagged default value. The proposed posting, with all its lines, is presented in full for approval.
Approving and posting
The invoice reaches the Finance inbox as an ‘Approval · invoice’ request containing the match result for each line, the proposed posting, the matching detail and three actions: approve, change or reject.
Show the figure
The approval request
Finance inbox
Approval · invoice
- Match result per line
- Proposed posting with all its lines
- Differences with their recipient: Purchasing or the person who recorded the delivery note
- Approval log: each decision and who took it
- Operations log: invoice reading, line matching and the formula applied
Show details
Finance's approval authorises the two operations: the invoice is recorded as checked and posted as proposed. Choosing Change opens the proposed posting for editing before it is recorded; choosing Reject leaves the invoice unposted, with the reason, and alerts Purchasing if the reason concerns the supplier.
An invoice with no decision stays pending and is neither recorded nor posted. If the purchase order or the delivery note changes between the proposal and the approval, the agent updates the proposal and requests approval again; an approval is never applied twice.
Every decision is recorded in the approval log, alongside the operations log. The approval log is applied to the next invoice from the same supplier: a ledger account corrected by Finance is proposed as a change to the formula, which takes effect only once Finance approves it, and a price accepted by Finance is used only once Purchasing records it in the supplier's terms.
In this use case every posting requires approval. If the company decides that invoices with no differences should be posted without going through the Finance inbox, that rule is written into the map and recorded in the approval log; the agent never sets such a rule itself.
Design criteria
Matching uses references in sequence, and the amount is compared only after each line is matched. Matching by amount links lines from different purchase orders whenever the amounts coincide, and hides the real difference.
The share of postings that can be automated depends on how consistent the company's past bookkeeping is, not on the calculation itself: neither a system nor a person can reproduce an accounting rule that changed mid‑year, or two identical lines posted with different expense types. The agent reports such cases as accounting practices still to be standardised.
Company decisions
Three decisions specific to each company determine what the agent flags and proposes.
Price and quantity tolerances
The company sets how large a price or quantity difference can be before the agent flags it, such as a rounding difference or a small variation in carriage. Without a defined tolerance, the agent flags every difference.
Agreed terms
Price comparison requires each supplier's terms to be recorded in the ERP and up to date. A price agreed but not recorded is flagged as a difference until Purchasing records it.
Language model and hosting region
The language model that reads new formats, its provider and the region where it runs are chosen during rollout; the model receives only the invoice file. The company signs the contract with the model provider.
Rollout
Rollout begins with the data map for purchasing and supplier invoices and with a test run matching invoices already posted, before the agent proposes posting any new invoice. Hellomatik builds the map from the data the company supplies; the company neither accesses the technical console nor writes the map. The use case has no fixed timetable.
- 01
Company map
Hellomatik defines the use case's sources: the mailbox or supplier portal, and the ERP records for purchase orders, delivery notes, suppliers, agreed terms, expense families and cost centres. The agent only reads from the ERP, except for the use case's two operations, which run only after Finance approves them.
- 02
Invoice readers by format
Hellomatik builds a reader for each format the main suppliers use, based on their invoices from previous months. The first invoice in a new format is held as an outstanding query until a reader for that format has been tested.
- 03
Testing the accounting formula
Hellomatik and Finance define the formula for ledger account, cost centre and expense type, and test it against the invoices posted in the last financial year. Finance reviews every difference and standardises the inconsistent accounting practices behind them before rollout continues.
- 04
Inbox and approvals
The company assigns the person who approves postings and the recipients of price and quantity differences. Once both roles are assigned, the agent reads the mailbox and Finance approves, changes or rejects each proposed posting.
Limits of the use case
The use case does not state what share of invoices match the purchase order and the delivery note at the first attempt, or how much time is saved. No company is running this use case yet: both figures are measured on the invoices of the company that adopts it.
The use case does not claim that every format is read equally well. A PDF made from a photograph falls outside the use case: the whole invoice is flagged as an outstanding query, with the image attached, for manual entry. In the formats that are read, any line that cannot be read with confidence is flagged as an outstanding query.
The use case does not cover the tax treatment of the invoice. VAT, reverse charge, intra‑community transactions, withholding tax, credit notes and corrective invoices fall outside it: the agent carries them into the proposed posting exactly as the invoice states them, and Finance resolves them. Nor does the use case cover a closed accounting period: an invoice dated in a closed period is flagged as an outstanding query.
Book a meeting with a Hellomatik engineer to review how supplier invoices are matched in your company today.
Or request a meeting here