ENZAXGENZAX AI Financial Document & Invoice Processing System
GENZAX portfolio project — designed, built and tested in-house; not commissioned by a client. It runs with test mode on, against a batch of twelve synthetic documents. No real financial account, payment system or vendor record is connected, and no payment has ever been made by it.
A financial document pipeline that takes an incoming document, classifies it, extracts and validates the invoice data, checks it for duplicates and anomalies, scores the risk on an explainable 0–100 scale, and routes it by that score — so routine invoices flow through and anything high-risk, high-value, duplicated or anomalous stops for a person.
PROBLEM
Accounts payable is where a business quietly loses money to its own process. Documents arrive in every format from every supplier, and someone has to work out what each one is, read the numbers off it, check the line items actually add up to the total, notice that this invoice is the same one that came in three weeks ago under a different reference, spot the amount that is well outside what this vendor normally bills, decide whether it needs a second pair of eyes, and then keep track of when it is due. Done by hand it is slow, and the two failures that matter most — paying a duplicate and paying something nobody checked — are exactly the ones a tired person is most likely to make.
APPROACH
Automate the reading and the checking; route the judgement to a person by risk rather than by volume. Every document is scored on an explainable 0–100 scale where each contributing factor is recorded, so an approver sees why something was flagged instead of being handed a verdict. The rule that shapes the build is absolute: high-risk, high-value, duplicate and anomalous documents are never auto-approved. The AI recommends, a human decides, and everything either of them did is written to an audit log.
SOLUTION
Built in n8n as twenty numbered modules across five stages. Intake and validation take the document in, check it and classify what type it is. AI extraction and understanding pull the financial data out, interpret the invoice and validate it against itself — line items, totals, tax, payment terms. Risk and anomaly run duplicate detection, expense categorization, anomaly detection and the risk score. A switch then routes by that score: normal documents take the automatic path, everything else goes to human review and approval, and the two routes merge back together so nothing is lost either way. The final stage stores the financial record, tracks payment and overdue status, runs the follow-up engine, produces financial analytics, and builds and stores the audit log.
WHAT IT DEMONSTRATES
- Explainable scoring — seven weighted factors, each recorded, so a risk score can be justified to an approver or an auditor
- Risk-based routing through a switch, with the automatic and human paths merging back into one record stream
- Hard human-in-the-loop rules: high risk, high value, duplicates and anomalies can never be auto-approved
- Self-consistency validation — an invoice checked against its own line items, totals and terms, not just parsed
- Duplicate detection as a first-class scored factor rather than an afterthought
- An audit log built and stored for every document, whichever route it took
- A test-mode flag on the trigger, so a demo run is explicit rather than assumed
WHERE THIS STANDS
The system is built and has been run end to end, but only in test mode: the trigger sets test_mode = true and the batch is twelve synthetic documents created for the purpose. No accounting system, bank, payment provider or vendor database is connected. No real invoice has been processed, no real vendor has been contacted and no payment has been made or scheduled. There are therefore no clients, no transaction volumes, no amounts processed, no savings and no ROI to report — and none are claimed anywhere on this page.
// MAIN FLOW
Document in, decision out.
Everything up to the risk score is preparation. The score is what decides whether the rest of the run needs a person.
// SYSTEM MODULES
Twenty modules, in five stages.
Each module is numbered on the canvas and owns one job, writing back to the same document record — which is what makes both the risk score and the audit log traceable to the step that produced each part of them.
Document intake
A financial document enters the pipeline and is normalised into one standard structure regardless of its original format or source.
Document validation
The document is checked for the fields and structure the later stages depend on, so a malformed file is identified before anything tries to read numbers off it.
Document classification
What kind of document this is — invoice, receipt, statement or other — decided first, because the handling after it depends on the answer.
Financial data extraction
Amounts, dates, references, vendor details, line items, tax and payment terms pulled into structured fields rather than left as text.
Invoice understanding
An AI step that interprets what the invoice is actually for and what it is asking the business to do, on top of the raw extracted values.
Invoice validation
The invoice checked against itself — do the line items sum to the subtotal, does tax apply correctly, does the total match, are the payment terms coherent.
Duplicate detection
The document compared against what has already been processed, so the same invoice arriving twice under different references is caught before payment, not after.
Expense categorization
Each document assigned an expense category from its own content, so the financial record is usable for reporting without a second manual pass.
Anomaly detection
Amounts and patterns that sit outside what is normal for this vendor or this category are flagged, with the reason recorded alongside the flag.
Financial risk scoring
A 0–100 score built from seven weighted factors, each contribution kept on the record so the number is fully explainable rather than a black box.
Approval routing
A rules-based switch routes by risk band: normal documents take the automatic path, everything else goes to human review.
Normal & review paths
Two explicit branches — an automatic route for low-risk documents and a human review route for the rest — rather than one path with a flag on it.
Human approval
A person approves, edits or rejects. High-risk, high-value, duplicate and anomalous documents can only ever leave the pipeline through here.
Merge & financial record
Both routes merge back into one stream and a structured financial record is stored, carrying the extracted data, category, risk score and approval outcome.
Vendor communication
Vendor-facing messages generated from the document's own details — no invented amounts, dates, disputes or payment commitments.
Payment status tracking
Where each approved document stands in the payment cycle, held as a field on the record rather than inferred from a chain of events.
Due date & overdue detection
Payment terms turned into a due date, and documents past it identified — the check that normally only happens when a vendor chases.
Follow-up engine
Structured follow-up on what overdue detection found, driven by the record rather than by somebody's memory.
Financial status management
One resolved status per document across its whole life — received, validated, scored, routed, approved, scheduled, paid or rejected.
Financial analytics
The processed set aggregated — what came in, what was flagged, what needed a human, what is outstanding and what is overdue.
Error handling & audit log
An audit entry built and stored for every document, on both routes, so what the system did and what a person decided is reconstructable afterwards.
// RISK SCORING
Where the score comes from.
Seven weighted factors summing to 100, each contribution stored on the record. Explainability is the point: a score that routes a payment to a human has to be defensible to that human, and later to an auditor.
- 20 points
- Invoice consistency — do the line items, totals, tax and terms agree with each other
- 20 points
- Duplicate signal — how strongly this document matches something already processed
- 15 points
- Data completeness — how much of what should be on the document is actually there
- 15 points
- Amount anomaly — how far the amount sits from what is normal here
- 10 points
- Vendor data — the quality and consistency of the vendor details supplied
- 10 points
- Payment terms — whether the stated terms are coherent and within expectation
- 10 points
- Evidence confidence — how much of the above is read from the document rather than inferred
0–29 · Low
Takes the normal route, provided it is not high-value, a duplicate or anomalous — those override the band and go to a human regardless.
30–59 · Medium
Routed to human review with the contributing factors surfaced, so the reviewer starts from what the system found rather than from the raw document.
60–100 · High
Always human. There is no configuration in which a high-risk document is approved automatically.
// SAFETY CONTROLS
What the automation is not allowed to do.
This pipeline decides whether money gets paid, so the limits are enforced in the workflow rather than left to configuration.
Never auto-approved
High risk, high value, duplicates and anomalies always route to a person. The AI recommends; a human decides.
Fully explainable scoring
Every point of a risk score traces to a named factor stored on the record, so no document is flagged without a reason attached.
No fabricated financial data
The system reads what the document contains. It does not estimate an amount, infer a tax figure or guess a payment term.
Audit log on every document
Both routes build and store an audit entry, so what happened to a document — and who decided it — can be reconstructed later.
No payments made
Nothing in the pipeline moves money. Payment status is tracked as a field; execution belongs to a finance system that is not connected.
Explicit test mode
The trigger carries test_mode = true and the batch is twelve synthetic documents, so a demo run is declared rather than assumed.
// BUILT TO DEMONSTRATE
System capabilities.
What the build actually does, verified by running the full test batch end to end. There are no client results here because there is no client.
CAPABILITIES
- Document intake, validation and type classification as a single front stage
- Structured financial data extraction — amounts, dates, vendor, line items, tax, terms
- AI invoice understanding on top of the extracted values
- Self-consistency invoice validation across line items, totals, tax and terms
- Duplicate detection against previously processed documents
- Automatic expense categorization
- Anomaly detection with the reason recorded alongside the flag
- Explainable 0–100 risk scoring across seven weighted factors
- Rules-based risk routing into automatic and human-review branches that merge back
- Human approval with hard non-auto-approval rules
- Structured financial records, payment status and due-date/overdue detection
- Vendor communication drafting and a follow-up engine
- Financial status management and aggregate analytics
- Error handling with an audit log built and stored for every document
// TECHNOLOGY
What it is built on.
Only what the build actually uses. Accounting, banking and payment integrations are what the architecture is shaped for, not what it currently has.
- Platform
- n8n. All twenty modules, the risk switch and both approval routes are n8n nodes.
- Trigger
- A test-batch trigger carrying test_mode = true, running twelve synthetic documents through the full pipeline.
- AI processing
- LLM-based structured analysis for invoice understanding, with the response parsed into fields the validation and scoring stages can act on.
- Data processing
- Code nodes for extraction, validation, duplicate detection, categorization, anomaly detection and scoring — the arithmetic kept out of the model so results are repeatable.
- Routing
- A rules-based switch on the risk band, feeding an automatic path and a human review path that merge back into one stream.
- Storage
- Structured financial records and a separate stored audit log, both in n8n-compatible storage.
- Mode
- Test mode. No financial accounts, payment systems, vendor data or production credentials are connected; the architecture is designed for them to be added.