Automate intake, validation, matching, and draft preparation; keep payment, tax/accounting approval, and disputed exceptions with authorized systems and qualified people. A model-extracted invoice is not financial truth.

// concept

Define Authorities

Fact	Authority
vendor identity	approved vendor master
purchase order	procurement system
goods/service receipt	receiving/project owner
invoice document	original stored artifact
totals/tax arithmetic	deterministic validation/accounting rules
payment status	bank/payment system
approval	authorized finance workflow

Create typed states: RECEIVED, VALIDATED, MATCHED, EXCEPTION, APPROVED, PAYMENT_PENDING, PAID, REJECTED. n8n coordinates but cannot invent transitions.

// concept

Build the Pipeline

// prompt — copy me8 lines

authorized intake → malware/type/size controls → document hash
→ deterministic field extraction or AI suggestion
→ schema and arithmetic checks
→ duplicate hash/invoice check
→ PO/vendor/receipt match
→ exception or review packet
→ external approval service
→ payment system reconciliation

Store document references, not broad copies in every node. Never collect bank passwords, PINs, or OTPs. Bind approval to vendor, bank account, invoice, currency, amount, and artifact hash; changes invalidate it.

Keep a reconciliation report that lists every intake document, resulting state, authoritative record, exception owner, and age. Counts must balance: received equals rejected plus exception plus accepted or in-progress. This prevents continue-on-fail branches from making invoices disappear without a visible financial control.

// worked_example

Worked Example

A Faisalabad textile firm receives a sample invoice. AI suggests invoice number/date/line fields, then deterministic code verifies sum and PKR currency. Vendor bank details differ from the approved master, so the workflow creates a HIGH-RISK exception; it does not update the master or proceed.

A finance officer verifies the vendor through an established independent channel. Payment is initiated outside model reasoning and marked PAID only after bank/provider confirmation. Duplicate webhook and invoice hash produce no second posting.

// failure_cases

Failure Cases to Diagnose

6 cases to diagnose

OCR confidence becomes approval
validate and review.
Vendor email changes bank details
independent verification required.
Invoice number alone deduplicates
combine vendor/document/evidence.
Model calculates totals
deterministic arithmetic.
Redirect/screenshot marks paid
server-side settlement evidence.
Document stored in execution history forever
apply retention/minimization.

// pakistan_angle

Pakistan Angle

Pakistani sales tax, withholding, and invoicing obligations require qualified accounting/tax advice and current official rules. Do not encode generic AI-generated tax percentages into production.

Bank-transfer and wallet reconciliation should use official transaction references. Protect CNIC/NTN/bank data and restrict document access by role.

// hands_on

Hands-On Exercise

5 steps

Map authorities and states.
build synthetic invoice intake.
add hash, schema, arithmetic, duplicate, and match checks.
create evidence-first exception review.
test changed bank, duplicate, wrong currency, payment retry, and retention.

// completion_rubric

Completion Rubric

6 checks — tick as you verify

0/6

// sources

Sources

3 official sources — check every claim yourself

// check_yourself

Check yourself

3 questions · answers and options are taken word-for-word from this course

0/3

1 / 3 · diagnose
Your work shows this failure mode: “Document stored in execution history forever.” What does the lesson tell you to do about it?