NORDVERIFY · AUDIT RECEIPT
EXAMPLE REPORT, NOT A CLIENT DELIVERY
The invoice automation looked fine. It wasn't sending a single invoice through.
This is a real example, built from an actual automation file, showing what an audit like this finds and how it gets reported back to you.
0
invoices getting through before the fix
1
thing I could not test myself, and said so
What I checked. I read the whole automation, end to end, and followed exactly what happens to an invoice from the moment it arrives by email to the moment it should land in the spreadsheet.
What I found. Three problems. The biggest one meant invoice data never reached the spreadsheet, not once, for any invoice, while everything looked like it was working.
What I did not check. I could not test the fix against a live account myself, so I have not confirmed it works yet. That's stated plainly below, not hidden.
For your technical person →
This example uses documented defects from a real n8n workflow file in the Nordverify repository. It demonstrates the report format. It is not presented as an audit of a customer or a current public n8n template.
CRITICAL · OBSERVED FAILURE
The attachment name was read from the wrong data object
What happened. The “Keep the PDFs” node tested $json.filename. The mail trigger was configured to put resolved attachments under $binary.attachment_0, so the requested JSON field was undefined. Every item threw before extraction.
Observed expression: {{ $json.filename }}
Observed error: TypeError in IfV1.node.ts:346 (Object.endsWith)
Measured output: 0 invoice fields extracted per PDFHuman impact. The workflow can look structurally complete while no invoice ever reaches the extraction step. A valid import or a valid JSON file would not catch this.
Fix direction. Read the filename from the actual binary attachment, for example ={{ $binary?.attachment_0?.fileName ?? '' }}, then test again with representative messages.
Source anchor: core/income/shelf/invoice-pdfs-to-sheet-rows/verification.json:8–14
HIGH · LIMIT FOUND BY INSPECTION
Only the first attachment is examined
What happened. The corrected expression still names only attachment_0. If a signature image is first and the PDF is second, the message can be dropped before extraction.
Human impact. Some invoices disappear based on attachment order, even though the email contains a valid PDF.
Fix direction. Iterate over all binary properties and route every matching PDF as its own item.
Source anchor: core/income/shelf/CLAIMS_AUDIT.json:41–45
MEDIUM · EXPRESSION CLASS
A missing leading “=” turns an expression into inert text
What happened. n8n expressions in parameter fields require expression mode. A copied value that looks like {{ $json.value }} but is stored as plain text can pass visual inspection while returning the literal text instead of evaluated data.
Human impact. The node may execute without an infrastructure error, but downstream systems receive the wrong value.
Audit check. Inspect expression-bearing parameters and verify their evaluated output with a known input; do not infer correctness from an import that completed without error.
Market/source record: n8n Community Questions feed, recorded in outreach/MARKET.json as “3 of the most-copied n8n templates ship a silent bug (an expression missing its leading =).”
VERIFICATION LIMIT
The proposed binary-path fix has not been tested again in n8n
The file was corrected and inspected, but this machine no longer had n8n available. Therefore this report does not call the fix verified. “Changed in the file” and “proved by testing it” are different states.
Source: core/income/shelf/invoice-pdfs-to-sheet-rows/verification.json:14, 27–37
Audit receipt
CHECKEDFile + evidenceJSON structure, node path, recorded error, output count, disclosed limitation.
FOUND3 classesWrong data object, first-attachment-only logic, inert expression risk.
NOT CHECKEDLive testCredentials, real mailbox behaviour, current n8n node compatibility, downstream Sheets write.