Process an incoming supplier invoice into the books

When to use

An invoice from a supplier has arrived and must end up booked and paid. Not for an invoice the company sends out — use money.issue-invoice. Not for a customer who has not paid — use money.chase-overdue-invoice. Not for deciding whether to buy at all — that is ops.purchase-approval, which should have run before the order was placed. A payment already made that does not match the bank statement is money.bank-reconciliation.

Before you start

• The supplier is in the supplier list, or ops.new-supplier has already run for it.
• The purchase was approved if it is above the company's threshold (ops.purchase-approval).
• The agent can read the company mailbox where invoices arrive (bc mail search).

What a run requires2

The trail9 steps

1. S1

   Collect and attach the invoiceagent

   Find it in the mail (bc mail search from:<supplier> has:attachment), save the original file into the documents module, and note the e-mail thread it came with. Paper: scan it (documents.scan-paper).

   Done when the invoice file exists in the documents module with supplier and date visible.

2. S2

   Check the supplieragent

   Match the sender and the invoice header against the supplier list: name, registration number, VAT number, bank account. If any of these differ from the last paid invoice, stop and treat it as a change of details.

   Done when the invoice's supplier data matches the list, or a discrepancy is written down.

   ⛔ A changed bank account in an e-mail is the classic fraud pattern — never accept new details from the invoice or an e-mail alone; call the supplier on the number already in the list.

3. S3

   Check the invoice contentagent

   Read back: supplier and buyer details, invoice number and date, description, quantity, unit price, total, VAT rate and VAT amount, due date, payment details. For a Latvian supplier, check the invoice carries the fields the VAT law requires. ⚠ verify mandatory invoice fields — Latvian VAT law, likumi.lv.

   Done when every field is present and the VAT amount equals base × rate, or the invoice is flagged invalid.

4. S4

   Match to what was receivedagent

   Three-way match: invoice ↔ purchase order or contract ↔ delivery/receipt. Price and quantity must agree.

   Done when the match is recorded, or the mismatch is listed with the supplier to be queried.

   ⛔ Booking an invoice that nobody can match to a delivery is how ghost purchases get paid.

5. S5

   Book itagent

   Enter the booking in the money module: expense account, cost centre, period = invoice date (not payment date), input VAT split out. Foreign currency: book at the invoice amount and record the rate used. ⚠ verify correct expense account in the company's chart of accounts — ask the owner if it is a new cost type.

   Done when the booking exists and its total equals the invoice total to the cent.

6. S6

   Approve the paymentownerneeds approval · owner

   Approval · S6 · owner — the run stops until a named person records the decision

   Show the owner: invoice, match result, booking, due date, amount. The owner approves payment or queries it.

   Done when a named person's approval is recorded with date and amount.

   ⛔ Routine small amounts may be pre-approved by policy — but the policy must name the threshold and the person.

7. S7

   Payagentirreversible

   Irreversible · S7 — an agent never closes it alone

   Pay from the approved bank account to the account confirmed in S2, reference = invoice number. Schedule on or before the due date if paying later.

   Done when the bank shows the outgoing payment with the invoice number as reference.

8. S8

   File and closeagent

   Mark the invoice paid, link the payment confirmation and the booking to the invoice record, set the retention period (documents.archive-retention), and clear the payable watch. If the invoice thread had attachments that are not the invoice, note them.

   Done when one link opens: invoice → booking → payment confirmation.

9. S9

   Hand backagent

   Send the owner a two-line summary: what was booked and paid, from which account, when.

   Done when the summary is sent.

Checks — how we know it worked

• Booking total = invoice total, VAT amount = invoice VAT, period = invoice month (read all three back).
• Paid amount = booked amount, and the payment appears in money.bank-reconciliation on the next run.
• No other booking exists for the same supplier + invoice number (duplicate check before S5).
• The filed document is the original invoice, not a screenshot or a forwarded copy.

If it goes wrong

What each step leaves behind

1. S1the invoice file exists in the documents module with supplier and date visible.
2. S2the invoice's supplier data matches the list, or a discrepancy is written down.
3. S3every field is present and the VAT amount equals base × rate, or the invoice is flagged invalid.
4. S4the match is recorded, or the mismatch is listed with the supplier to be queried.
5. S5the booking exists and its total equals the invoice total to the cent.
6. S6a named person's approval is recorded with date and amount.
7. S7the bank shows the outgoing payment with the invoice number as reference.
8. S8one link opens: invoice → booking → payment confirmation.
9. S9the summary is sent.

Evidence to keep

Invoice file (original) · supplier match note with date · booking id and period · the S6 approval (who, when, amount) · payment reference from the bank · the query thread if the supplier was asked anything.

How this playbook improves

After every 25 invoices ask: how long from receipt to booked, and which step waited longest? Did any invoice reach S6 without a match in S4? Was any input VAT corrected after the VAT return? Did any supplier details change without the S2 check catching it? A new version changes the step that failed and says so in its change note.