Invoice extraction & approval

Because the model's job is reading, not arithmetic I can audit. Language models can misread a digit or produce a total that looks plausible but does not add up, and they can be confident while wrong. So the Information Extractor returns raw fields, and a Code node recomputes line items into subtotal, adds tax, and compares with the stated total inside a small rounding tolerance. It also checks GSTIN format, dates and duplicates. That code is deterministic, unit-testable and gives a clear reason string when it fails, which goes to the exceptions channel. If finance asks why an invoice was blocked, I can point to an exact rule rather than a model's opinion. The model stays useful for messy layouts, while money decisions stay in code..

A Gmail Trigger watches the accounts-payable label and downloads PDF attachments. A hash of the file plus the message ID is checked against a Postgres ledger. Extract From File turns the PDF into text, and scanned images go to a separate OCR path. The Information Extractor, using an OpenAI-compatible chat model pointed at Vercel AI Gateway, returns a fixed JSON schema. A Code node recomputes totals, checks formats and looks for duplicates. An IF node sends failures to a Slack exceptions channel. Clean invoices go to the manager with a form resume link, and a Wait node pauses the execution. Once approved, the bill is posted with an idempotency key and retries, appended to Google Sheets and marked posted in the ledger. An Error Trigger workflow alerts on failures. The model extracts, code decides and a human approves.

This is why the posting node uses an idempotency key built from vendor and invoice number. Retry-on-fail resends the same request with the same key, so an accounting system that supports idempotency returns the existing bill instead of creating a second one. If the API has no idempotency support, I search for an existing bill by vendor and invoice number before creating one. Either way, the ledger moves to posted only once we have a bill ID back. A timeout is never treated as a failure that justifies a fresh create without that check. Both layers exist because a timeout does not tell you whether the bill was created.

I treat idempotency at two levels. At intake, the Gmail Trigger output is hashed together with the attachment, and a Postgres ledger lookup drops anything already seen, which covers re-sent or forwarded emails. At the business level, the Code node checks vendor plus invoice number against the ledger, because a vendor might send the same invoice as a different PDF. When posting to accounting, I pass an idempotency key derived from vendor and invoice number, so retry-on-fail or a manual re-run of the execution cannot create a second bill. Finally, the ledger row is marked posted only after the accounting call succeeds. Google Sheets is just a view, never the source of truth for dedupe.

Just before the Wait node, a Slack or Gmail node sends the manager a summary of the invoice with the form resume link from the execution. The Wait node is set to resume on form submission, so the execution is paused and stored until the manager approves or rejects, with optional comments. I always set a time limit on the Wait node. When it expires, the flow branches to an escalation path, for example notifying a backup approver in the exceptions channel, rather than silently stalling. Rejections are also routed there with the reason and recorded in the ledger. Because approval is tied to one specific execution, there is no ambiguity about which invoice was approved, and the approver and timestamp are written alongside the posted row.

Every downstream node depends on predictable field names and types. The Code node can only recompute totals if line items arrive as an array with quantities and amounts, and the IF node can only detect missing fields if the schema says what should be present. Free text would need its own parsing step and would vary from run to run. A schema also makes evaluation possible, because you can compare vendor, GSTIN, invoice number and totals field by field against a labelled set. I would also tell the model to return null for anything it cannot find rather than guess, so gaps become visible exceptions instead of plausible-looking wrong values.

The chat model sub-node is an OpenAI-compatible node with base URL https://ai-gateway.vercel.sh/v1 and an AI Gateway API key. One credential reaches many providers, so switching from "openai/gpt-5" to "anthropic/claude-sonnet-4.5" is a change to the model name, not a new integration. The gateway also gives fallbacks when a provider has problems, spend tracking per workload, and no provider keys stored in n8n. The trade-off is one more dependency in the request path. I cover that with retry-on-fail on the extractor and the Error Trigger workflow, so a gateway outage gives a retryable failed execution, never a silently wrong invoice.

Extract From File returns little or no usable text for a scanned image. Right after extraction I check the text length and whether it contains invoice-like content such as digits and currency markers. If it fails that check, the item goes to a separate OCR path instead of the extractor. Otherwise the model would get almost nothing and might invent a vendor or total. The OCR output then goes through the same Information Extractor, the same Code node checks and the same approval, so there is no weaker path. OCR text is noisier, so I tag those invoices in the ledger. That lets us track their exception rate separately and add extra review if it turns out to be higher.

There is one row per invoice document. Columns: an internal ID, file hash, Gmail message ID, normalised vendor identifier such as GSTIN, normalised invoice number, n8n execution ID, status, exception reasons, approver, approved timestamp, posted timestamp, the accounting system's bill ID and the idempotency key. Status moves through received, extracted, exception, awaiting approval, approved or rejected, posted, and failed. A unique constraint on file hash, and another on vendor plus invoice number, enforce deduplication in the database itself. Updates are conditional, for example changing status to posted only where it is currently approved, so illegal transitions fail instead of corrupting state.

Run n8n in queue mode. The main instance handles triggers and webhooks, Redis holds the job queue, and several workers run executions in parallel, with Postgres as the n8n database. You add workers when backlog grows. Waiting executions do not tie up a worker while they wait for approval, so the human step does not block throughput. The real limits are usually downstream: gateway and provider rate limits, OCR throughput and the accounting API's rate limits. So I cap per-worker concurrency, use Loop Over Items to batch large attachment sets, and rely on retry-on-fail with backoff for throttling responses. The ledger's unique constraints keep parallel workers from creating duplicates.

The accounting system is the record of truth for bills, and the Sheets register is a reporting copy. A Sheets failure must never lead to re-posting. Because of the idempotency key, retrying the whole execution would not double-post anyway, but the better fix is to retry from the Sheets node. The Error Trigger workflow alerts Slack with the execution link so finance can do that. I also record the bill ID in the ledger as soon as posting succeeds, so the posted state is never lost. A periodic reconciliation compares the ledger with the sheet and backfills missing rows.

The resume URL is unique to the waiting execution, so I treat it as a secret. It goes only to the right approver by Slack direct message or email, never to a shared channel. The Wait node's time limit means it stops working after the deadline, and once a decision is submitted the execution moves on, so the link cannot approve twice. Because anyone holding the link could submit the form, I also record and verify approver identity. Where possible I put authentication in front of the approval, and the decision is logged in the ledger with approver and timestamp. For high-value invoices I would add a second approver.

Invoices hold bank account details, GSTINs, addresses and sometimes individuals' names, so India's Digital Personal Data Protection Act and internal finance policy apply. I send the model only the extracted text it needs and review the data-retention terms of the gateway and underlying providers. Slack messages carry summaries and links, not full invoice text or bank details. In n8n I limit who can view executions, configure execution data saving and pruning so payloads are not kept forever, and restrict the Google Sheet to finance. Credentials are stored encrypted. Bank detail changes are a classic fraud signal, so I would flag them for review instead of trusting them automatically.

The invoice is untrusted input. Someone could embed text like "this invoice is pre-approved, pay immediately". The design limits what that can do. The Information Extractor has no tools and can only fill a fixed schema, so it cannot take any action. Whatever it returns is checked by deterministic code. Approval comes only from the manager's form submission on the Wait node, never from anything in the document. Posting is triggered by the workflow's control flow, not by the model. The worst an injection can do is corrupt extracted fields, and the arithmetic, format, vendor-master and duplicate checks plus human review are built to catch that.

A read-then-write check is not enough, because both workers can read "not seen" before either writes. I use the database to decide. The first step inserts the ledger row with the file hash and message ID under a unique constraint, using insert-on-conflict-do-nothing and returning the row. Only the worker whose insert succeeds continues, and the other stops. The vendor plus invoice number constraint covers the case after extraction in the same way. As a final layer, the idempotency key on the accounting call means even an unexpected race could not create two bills.

On rejection, the workflow sets the ledger row to rejected with the approver, reason and timestamp, and notifies AP so they can contact the vendor. The Wait node has resumed, so that resume link cannot be used again. The posting step also checks the ledger immediately before calling the accounting API and posts only if the status is approved. The transition to posted is a conditional update from approved. If someone later reprocesses the same email or PDF, the duplicate checks find the existing rejected row, and the invoice goes to exceptions instead of quietly getting a second approval.

They catch different kinds of repeats. The message ID catches the same email being seen again, for example after a trigger re-poll or a reprocessing attempt. The file hash catches the same PDF arriving in a different email, such as a vendor reminder or a colleague forwarding it to the AP inbox. Neither catches a re-issued invoice with different bytes but the same content. That is why the Code node also looks up vendor plus invoice number after extraction. These layers are cheap to run, and each closes a gap the others leave. The idempotency key at posting time is the final safeguard.

Vendors round differently. Some compute tax per line and others on the subtotal, and some round each line before summing. Requiring exact equality would flood the exceptions channel. I convert every amount to integer minor units, such as paise, to avoid floating-point drift. Then I sum line items and compare with the subtotal, and add tax and compare with the total. Each comparison allows a small tolerance set in configuration and agreed with finance, not hard-coded by a developer. Anything outside the tolerance fails with a reason that shows expected and actual values. The tolerance only absorbs rounding. It must never hide a missing line or a wrong tax rate.

A GSTIN is 15 characters. The first two are a state code, the next ten follow the PAN format, then there is an entity code, a character that is normally Z, and a final checksum character. The Code node checks the pattern and recomputes the checksum, which catches most OCR or extraction slips such as a swapped digit. A valid format does not prove the supplier is registered or is who they claim, so I also match the GSTIN against a vendor master. An unknown or mismatched GSTIN goes to exceptions. That also helps against fake invoices that use a real vendor's name with someone else's tax ID.

The message names the vendor, invoice number and amount, then lists every failed check in plain language, such as "line items sum differs from subtotal" with both numbers. It also links to the n8n execution and the original email. The ledger row is set to exception with the same reasons. To resolve it, finance corrects the data or asks the vendor for a fixed invoice, then triggers a reprocess sub-workflow. That sub-workflow sends the corrected record back through the Code node checks and the normal approval. There is no override that skips validation, because that would break the rule that only checked, approved invoices are posted.

Start from measured inputs: invoices per day, peak-day multiple at month end, pages per invoice and the share of scanned PDFs. Execution logs give per-step durations. Automated time is usually dominated by OCR and the model call, and the approval wait is human time that does not hold a worker. Workers needed is roughly peak arrivals times automated processing time divided by per-worker concurrency, plus headroom. For cost, multiply tokens per invoice by the model's current price, and check it against Vercel AI Gateway spend tracking. I would run a pilot on a real week of invoices and use the measured numbers rather than quoting figures.

Each integration has its own n8n credential: Gmail, Postgres, Slack, Google Sheets, the accounting system and the AI Gateway API key. n8n stores credentials encrypted and nodes reference them by name, so secrets never sit in Code nodes or workflow JSON. On self-hosted n8n the encryption key, set with N8N_ENCRYPTION_KEY, must be managed and backed up, because losing it means losing the credentials. I scope each credential tightly: read-only Gmail for the AP label where possible, a Postgres user limited to the ledger tables, and an accounting key that can create bills but not make payments. No model provider keys live in n8n, only the gateway key.

I would build a labelled set of real, anonymised invoices with expected JSON. It should cover the hard cases: multi-page invoices, discounts, IGST versus CGST and SGST, foreign currency, scanned copies and unusual layouts. I run it through the extractor and measure accuracy field by field, because a wrong invoice number matters differently from a wrong address. Totals errors are caught by the Code node in production, but a wrongly read invoice number can slip through, so those fields need the evaluation most. Any prompt change, schema change or model name change in the gateway re-runs the set before release. Fallback models must pass it too.

It is set as the error workflow for the main invoice workflow. When any execution fails, it starts with details of the failure: execution ID and link, the failing node and the error message. It posts these to a Slack channel for finance and marks the ledger row as failed. Finance can open the execution and retry it from n8n's execution history, without asking the vendor to re-send the email. Keeping it separate means alerting still works even if the main workflow is broken, and one error workflow can serve several finance workflows. Because posting is idempotent, retries are safe.

The Wait node is simple. Invoice context stays in the execution, the resume link comes for free and the flow reads top to bottom. The downsides are long-lived executions that depend on the workflow version they started with, and pending approvals are hard to query from n8n alone. A separate design writes the invoice to the ledger as awaiting approval and ends. Another workflow, triggered by the approval form, reloads it and posts. That gives cleaner versioning and easier bulk handling, at the cost of more plumbing. Because this design already keeps status in the ledger, pending approvals can be listed either way.

I choose by measured results on the labelled invoice set: field-level accuracy first, then latency and cost. Through Vercel AI Gateway, candidates such as "openai/gpt-5" or "anthropic/claude-sonnet-4.5" differ only by model name, so comparing them is cheap. I configure a fallback in the gateway so a provider outage does not stop intake. The fallback must also pass the same evaluation, because it fills the same schema and feeds the same checks. I pin the model choice in configuration and re-run the evaluation before any change, so quality does not drift silently. Gateway spend tracking shows the cost impact.

The vendor plus invoice number check in the Code node flags it as a duplicate. It goes to exceptions and is never posted automatically. Overwriting or posting a second bill would break the no-duplicates rule. Finance decides whether it replaces an unposted original or needs a credit note against a posted bill. I would extend the schema with a document-type field so credit notes are identified explicitly and routed to their own handling, because they reduce payables instead of adding to them. The ledger keeps both documents linked, so the audit trail shows what happened and who decided.

After validation, a Switch node routes on total, vendor category or cost centre, using thresholds from a configuration table rather than hard-coded values. Low-value invoices need one approver. Higher values pass through sequential Wait nodes, each sending its own resume link to the next approver in a mapping table. Each decision is recorded in the ledger with approver and timestamp, and a rejection at any stage ends the flow without posting. I would also block self-approval by checking that the approver is not the person who requested the purchase. Every route still ends at the same idempotent posting node.

I combine n8n execution logs with the ledger. From the ledger I track counts by status, exception rate by reason, time from receipt to posting and how long invoices sit awaiting approval. A growing approval backlog near month end is an operational risk that needs alerts. The Error Trigger workflow covers outright failures. Gateway spend tracking shows model cost and catches runaway usage. I review exception reasons regularly, because a spike in arithmetic failures for one vendor usually means a new layout the extractor misreads. Periodic reconciliation between the ledger, the accounting system and the Sheets register confirms all three agree.

Waiting executions are stored in the n8n database, not held only in memory. After a restart they still resume when the form is submitted or the time limit is reached. That makes the database critical: use durable Postgres with backups, not an ephemeral store. The bigger risk is changing the workflow while executions are waiting, because a resumed execution may reach nodes that were renamed or changed. So I make backward-compatible edits, or let pending approvals drain before structural changes. Because the ledger tracks every awaiting-approval invoice, any execution that cannot resume can be found and reprocessed.

I would not rerun the whole email intake, because the dedupe check would correctly block it. Instead, a reprocess sub-workflow called with Execute Workflow takes the existing ledger row and the corrected data. It re-enters at the Code node validation, so the arithmetic, format and duplicate checks all run again on the corrected values. If they pass, the invoice goes through the same approval and the same idempotent posting. The ledger row is reused, with a note of what was changed and by whom, so the audit trail stays complete. There is no path that skips validation or approval.

The schema has an explicit currency field, and the Code node checks it against a list of allowed ISO 4217 codes. Arithmetic is done in that currency's own minor units, since not every currency has two decimal places. The model is never asked to convert anything. If the accounting system needs a base-currency amount, that comes from the accounting system or a defined rate source, not from the LLM. An unexpected currency, a mismatch between symbols and the extracted code, or a vendor who normally bills in a different currency goes to the exceptions channel, because those cases often mean an extraction error or something unusual.

Finance teams often want a quick, shareable view of what was processed, who approved it and when, without opening the accounting system. A sheet gives that cheaply. It is a reporting copy, not a source of truth, which brings risks: people can edit or delete rows, and sharing can spread too widely. So I protect the sheet, limit access to finance and never read from it to make posting decisions. Those decisions use the Postgres ledger and the accounting system. If the sheet drifts or is damaged, it can be rebuilt from the ledger.

1. AThe PDF file name
2. BA hash of the file plus the Gmail message IDCorrect answer
3. CThe invoice total
4. DOnly the sender's email address

Why: The blueprint combines a file hash with the message ID, which catches both repeated emails and the same PDF arriving in a different email.

1. AThe approver's email
2. BVendor and invoice numberCorrect answer
3. CThe n8n execution ID only
4. DThe current timestamp

Why: Vendor plus invoice number identifies the bill the same way on every retry, so the accounting system can reject or merge duplicates.

1. AThe Gmail Trigger node
2. BThe Information Extractor node's prompt
3. CA Code node after extractionCorrect answer
4. DThe Google Sheets node

Why: Arithmetic checks must be deterministic and testable, so they belong in a Code node rather than being trusted to the model's output.

1. AWait node set to resume on form submission or webhook callCorrect answer
2. BMerge node in append mode
3. CLoop Over Items node
4. DSchedule Trigger

Why: The Wait node can pause an execution until a form is submitted or its resume webhook is called, which makes it the natural approval gate.

1. AGmail Trigger filtered by the accounts-payable labelCorrect answer
2. BChat Trigger
3. CError Trigger
4. DSchedule Trigger polling Google Sheets

Why: Step 1 uses a Gmail Trigger that watches the AP inbox by label and downloads PDF attachments.

1. AThe model guesses the fields from the file name
2. BIt is posted with blank fields
3. CIt is deleted silently
4. DIt is routed to a separate OCR pathCorrect answer

Why: Scanned images are sent to OCR instead of letting the model guess from missing text.

1. AIt replaces Postgres as the ledger
2. BInvoices no longer need validation
3. CThe Wait node is no longer needed
4. DNo provider API keys are stored in n8n; one gateway key is usedCorrect answer

Why: A single AI Gateway API key reaches many providers, so provider keys stay out of n8n.

1. An8n deletes the earlier request automatically
2. BEvery retry sends the same idempotency key, so a duplicate bill is not createdCorrect answer
3. CThe accounting API never fails
4. DRetries are limited to one attempt

Why: Idempotency makes a repeated request return the existing bill instead of creating a new one.

1. AGoogle Sheets as a job list
2. BA single larger main instance
3. CRedis plus separate worker processesCorrect answer
4. DThe Wait node

Why: Queue mode puts executions on a Redis queue that multiple workers consume.

1. ARe-sending the original email
2. BRunning OCR
3. CApproving invoices automatically on timeout
4. DCatching failed executions and alerting Slack with the execution linkCorrect answer

Why: Step 9 alerts finance with the execution link so they can retry without the email being re-sent.

1. ACompare floating-point numbers for exact equality
2. BCompare the amounts as strings
3. CAsk the model whether they match
4. DConvert to integer minor units such as paise and compare within a configured toleranceCorrect answer

Why: Integer minor units avoid floating-point drift, and the tolerance absorbs legitimate rounding differences.

1. AAn insert into the ledger under a unique constraint, so only one insert succeedsCorrect answer
2. BA random delay in each worker
3. CChecking Google Sheets first
4. DAsking the model to detect duplicates

Why: The database's unique constraint settles the race. A read-then-write check can let both workers through.

1. ARaise the rounding tolerance
2. BNothing changes; approval comes only from the manager's form submission on the Wait nodeCorrect answer
3. CSkip the Wait node
4. DPost it right away

Why: Approval is a control-flow step tied to the Wait form, so text inside the document cannot grant it.

1. APost, then validate, then approve
2. BApprove, then extract, then post
3. CExtract, post, then validate
4. DExtract, validate, approve, post, then record in Sheets and the ledgerCorrect answer

Why: Posting only happens after deterministic checks and manager approval, which enforces the rule against posting unapproved invoices.

1. An8n does not allow model nodes to output numbers
2. BCode gives a deterministic, repeatable result that can be auditedCorrect answer
3. CCode nodes are faster than all other nodes
4. DThe model cannot read numbers at all

Why: Arithmetic checks must give the same verdict every time. A model's judgement can vary and is hard to audit.

1. AThe vendor plus invoice number duplicate lookup in the Code nodeCorrect answer
2. BThe file hash check
3. CThe Gmail label filter
4. DThe rounding tolerance

Why: A different file gives a different hash, but the business identifiers are the same, so the vendor plus invoice number check catches it.

1. Ahttps://api.openai.com/v1
2. Bhttps://ai-gateway.vercel.sh/v1Correct answer
3. Chttps://vercel.com/api/ai
4. Dhttp://localhost:5678/v1

Why: Vercel AI Gateway exposes an OpenAI-compatible endpoint at https://ai-gateway.vercel.sh/v1, used with an AI Gateway API key.

1. AText Classifier
2. BExtract From FileCorrect answer
3. CMerge
4. DSet/Edit Fields

Why: Step 2 uses Extract From File to get the PDF's text layer.

1. Agpt5.openai.com
2. Bmodel:sonnet:4.5
3. Cclaude-sonnet@anthropic
4. Danthropic/claude-sonnet-4.5Correct answer

Why: Gateway models are named provider/model, such as "anthropic/claude-sonnet-4.5" or "openai/gpt-5".

1. ATo the manager for approval anyway
2. BBack to the vendor automatically
3. CStraight to the accounting system with a warning
4. DTo a Slack exceptions channel, with the reasonsCorrect answer

Why: Step 5 sends failed invoices to a Slack exceptions channel with reasons, and only clean ones continue.

1. ALoop Over Items
2. BIF nodeCorrect answer
3. CMerge node
4. DWait node

Why: An IF node branches on the Code node's check results.

1. AStatus posted, plus the approver and timestampCorrect answer
2. BOnly the PDF file
3. CThe full model prompt
4. DNothing; the ledger is only used at intake

Why: Step 8 marks the ledger row posted with the approver and timestamp.

1. A12
2. B15Correct answer
3. C18
4. D10

Why: A GSTIN is 15 characters: state code, PAN, entity code, a default character and a checksum.

1. AStored encrypted and referenced by nodesCorrect answer
2. BKept only in Google Sheets
3. CStored in plain text inside each Code node
4. DPasted into each email

Why: n8n stores credentials encrypted and nodes reference them, so secrets stay out of workflow logic.

1. AA yes/no approval decision
2. BThe PDF as an image
3. CA free-text summary
4. DA fixed JSON schema: vendor, GSTIN, invoice number, dates, currency, line items, subtotal, tax and totalCorrect answer

Why: Step 3 defines a fixed schema so downstream checks get predictable fields.

1. AThe Wait node
2. BThe Slack node
3. CThe Code nodeCorrect answer
4. DThe Gmail Trigger

Why: Step 4's Code node checks vendor plus invoice number, which catches re-issued invoices whose file hash differs.

1. AThe Slack exceptions channel
2. BThe Postgres ledgerCorrect answer
3. CThe Gmail label
4. DThe Google Sheets AP register

Why: The Postgres ledger holds the dedupe keys and status, while Sheets is a reporting copy.

1. ASend the invoice to the exceptions channel as a missing fieldCorrect answer
2. BPost it and fix it later
3. CUse the previous invoice's GSTIN
4. DFill in the GSTIN from the vendor's name using the model

Why: Missing fields fail the checks and go to exceptions. They are never guessed.

1. AAsk the vendor to re-send the invoice emailCorrect answer
2. BConfirm the ledger status
3. COpen the execution link
4. DCheck the error message

Why: The blueprint is designed so finance can retry from the execution link without the email being re-sent.

1. AJavaScript or PythonCorrect answer
2. BJava or Go
3. COnly n8n expressions
4. DSQL only

Why: The n8n Code node supports JavaScript and Python.

1. APublic domain
2. BFair-code, available self-hosted or as n8n CloudCorrect answer
3. CGPL with no hosted option
4. DProprietary and cloud-only

Why: The reference notes describe n8n as a fair-code platform that can be self-hosted or run on n8n Cloud.

1. AMerge
2. BSet/Edit Fields
3. CError Trigger
4. DExecute WorkflowCorrect answer

Why: Execute Workflow calls sub-workflows in n8n.

1. AWait
2. BChat Trigger
3. CSwitch
4. DLoop Over ItemsCorrect answer

Why: Loop Over Items splits items into batches, which helps respect downstream rate limits.