n8n Invoice Review Gate: Workflow, Tests & Outputs

A billing workflow needs a clear point at which it refuses to proceed. This implementation example puts that point before an invoice draft: approved amount, calculated line-item total, and billing identity must agree.

We built a small n8n workflow to make those checks inspectable. It uses synthetic records and makes no external calls. It is a lab example, with no customer data or claimed customer savings.

What the workflow does

The flow has three connected nodes:

Run sample starts a manual execution.
Sample records emits two synthetic billing records.
Validate for review checks the whole batch and returns a status for each record.

A valid record receives ready_for_review and a draft object. A rejected record receives needs_review, its reasons, and no draft. The workflow ends there; it does not send an invoice, charge a customer, or mark a bill as paid.

This matters when adding a later billing step. Route by the returned status and retain human approval. Output from an n8n node does not, by itself, establish that a record is suitable for a write operation.

Download and run the sample

Import the workflow JSON into a test n8n instance, open it, and choose Execute workflow. No credentials are needed. See n8n's import and export instructions for the current editor controls.

The manual sample imported and completed successfully in n8n 2.37.10 on September 7, 2026, using an isolated SQLite database and the JavaScript task runner. That runtime check covers the two built-in sample records. The additional fixture checks below execute the same Code-node source in Node.js; they are not a separate n8n runtime certification.

To reproduce those logic checks, save all three downloads in one folder and run this command with Node.js 22 or later:

node verify-invoice-review.mjs

The script checks the workflow's content hash, runs the fixture inputs, and compares the complete results with the saved expectations. It exits with an error if the code or results differ. Run only the supplied, trusted workflow: Node's VM module is not a security boundary for arbitrary downloaded code.

What passed, and what stopped

The fixture download contains the full input and expected output for each scenario. Amounts use integer cents in USD.

Scenario	Expected result	Why
Approved D-104: 250,000 cents of line items	Ready for review, draft present	Amounts and required fields agree
Approved D-105: 175,000 cents approved, 170,000 calculated	Needs review, no draft	Line items do not match approval
Approval missing	Needs review, no draft	Approval must explicitly be true
Same deal and billing version twice in a batch	Both need review, neither has a draft	A duplicate cannot silently choose a winner
Same deal with two distinct positive billing versions	Both ready for review	The batch identity includes the version
EUR currency	Needs review, no draft	This sample only accepts USD
Decimal unit amount	Needs review, no draft	Money must be represented in integer minor units
Missing customer reference	Needs review, no draft	There is no destination customer identity

ready_for_review describes these checks only. The customer reference has not been looked up in a billing platform, and a syntactically valid billing version has not been approved by an external system.

The boundary that duplicate checking does not cover

The key combines dealId and billingVersion. The validator counts that key across the current batch before producing drafts, so both copies of a duplicate are rejected.

It has no memory between executions. Run the valid sample twice and both runs can return a draft. The fixtures include that replay to make the limit explicit. Changing a version number also produces a different key; a production system must control who can authorize a new billing version.

For a connected implementation, persist the relationship between the approved source record and the provider's invoice ID. Reconcile an uncertain response before retrying a write. Use provider-supported idempotency where available, within that provider's documented scope and retention period. A local duplicate check alone cannot promise exactly-once billing.

What must be added for a firm's billing process

The next implementation decision is the approval boundary. Identify who can approve the amount, how changes invalidate that approval, and what evidence must remain available to a reviewer.

Then define the write and recovery behavior. A record can pass validation while the billing API is unavailable. Keep that state distinct from a rejected record and from a confirmed invoice, with an owner for unresolved runs.

This sample has no tax, credit, discount, foreign-exchange, partial-invoice, or refund rules. It also omits authentication, access controls, monitoring, retention policies, and connections to accounting software. Those belong in a scoped production build and its tests.

For an accounting team choosing its first workflow, the accounting automation guide compares this handoff with document collection and other practice workflows. The n8n templates collection includes two other runnable samples.

Apply this review gate to your tools

Our n8n consulting service covers workflow design, implementation, and operational handover. Bring a redacted approved record, proposed invoice lines, and the source and billing systems you use. Those are enough to start identifying validation rules and the decisions that need a human owner.

An n8n Invoice Review Gate You Can Reproduce