An n8n Invoice Review Gate You Can Reproduce
A credential-free implementation example: validate an approved amount, reject duplicate billing keys within a batch, and keep mismatched records out of a draft.
Recorded local demonstration
Watch the review gate run
This 90-second walkthrough shows the downloaded workflow in a local n8n 2.44.7 runtime with synthetic records. The result callouts are labelled CLI execution excerpts and edited annotations, so the saved output stays readable. One record reaches a simulated review queue. The mismatched record returns needs review with no draft or external write.
It is not a connected CRM or billing integration. The queue is simulated, no human approval is asserted, and the sample has no persisted cross-execution idempotency control.
Read a walkthrough summary
This is a local n8n demonstration with synthetic data. The Manual Trigger starts the demo, then Sample records emits two handoffs to the validation node.
D-104 has an approved amount and matching line items. It returns ready for review, with a simulated review-queue payload. No destination is connected.
D-105 has a mismatch between its approved total and line-item total. It returns needs review, states the reason, and produces no draft.
Before a real write, replace the sample node with an approved source read, define the reviewer and queue, persist destination identifiers, and test uncertain-write recovery with the target system.
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.
The recorded walkthrough above is an actual local execution, not a customer-system recording. It shows the downloaded JSON in n8n 2.44.7. To keep both outcomes readable, the result cards are visibly labeled as sanitized CLI execution excerpts and edited annotations. D-104 reaches a simulated review queue. D-105 returns needs_review on the amount mismatch. Neither record reaches a CRM, billing platform, or a human approver.
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
- Download the n8n workflow JSON.
- Download the validation fixtures and expected outputs.
- Download the standalone verification script.
- Read the MIT license.
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 first imported and completed in n8n 2.37.10 on September 7, 2026. On October 26, 2026, we repeated the import and execution in a fresh, isolated local n8n 2.44.7 SQLite sandbox using the JavaScript task runner. Both runs cover the two built-in synthetic records: D-104 returned ready_for_review with a draft payload; D-105 returned needs_review with Line total does not match approved total and no draft. This is runtime evidence for the downloaded sample only, not a certification of a CRM, billing, queue, or approval integration.
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.
The local result also does not prove a human approved D-104. ready_for_review is a validation outcome, not a delivery state. A production design needs a named review destination, the source record that establishes approval, persisted destination identifiers, and a recovery test for an uncertain write before it creates an invoice.
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.
Have a similar operating problem?
Tell us about the process and the decision you need to make.