Tutorial: attach payout evidence without wrong matches
A scheduled n8n pattern that attaches payout PDFs to the right Lexware vouchers: destination pre-checks, explicit match states, dry runs, paced writes, and per-item audit outcomes.
This sanitised Ko Kitchen tutorial covers the last mile of accounting automation: connecting a payout PDF to the correct Lexware card voucher. A voucher can be correct and still create future review work when the supporting evidence sits in another system.
Treat attachment as an evidence decision
The goal was not to upload every available PDF. It was to attach the correct payout report to the expected voucher while making a wrong association impossible to hide. That means matching has to produce an explicit decision, not the first plausible file.
Start from the destination record
Every day at 07:00, the n8n workflow reads a controlled attachment work set and processes one expected voucher at a time. For each work item, it first reads the live Lexware voucher and inspects its attachments. When the evidence is already present, it records that check and stops. Yesterday's successful upload becomes a no-op today.
Screenshot: attachment workflow topology
Add a sanitised workflow screenshot here. Show: Daily Schedule → Read Work Set → Read Voucher → Already Attached? → PDF Matched? → Dry Run? → Pace → Download → Attach → Verify. Remove voucher numbers, Drive IDs, file names, credentials, and live values.
Model matching as a decision table
Exactly one valid PDF means the item can continue. No candidate becomes NO_MATCHING_PDF. More than one candidate becomes AMBIGUOUS_MATCH. An already-attached source is recorded as an already-attached check. The important behavior is that ambiguity never falls through to upload.
This is a general document-matching rule: make every candidate set observable. A system with insufficient evidence should produce a reviewable status, not an arbitrary association.
Screenshot: match outcomes
Add a redrawn decision table here with four synthetic rows: exactly one match, no match, ambiguous match, and already attached. Show the recorded outcome only; do not show production records or file names.
Dry-run is a real workflow path
A valid match does not need an immediate write. In dry-run mode, the workflow records MATCHED_DRY_RUN and makes no Lexware request. That provides an operational boundary: evaluate matching rules against a real work set, inspect the proposed associations, then enable uploads only when the evidence is credible.
Control the external write
For a real run, the workflow paces Lexware requests at one attachment every 750 milliseconds. It downloads the selected Google Drive PDF, uploads it to the expected voucher, and verifies that the API response contains the returned file identifier. The final outcome is ATTACHED or ATTACH_FAILED, never an unrecorded attempt.
Every work item records a terminal state: already present, no match, ambiguous, matched in dry run, attached, or failed. This makes recovery local. An operator can inspect one failed item without repeating successful uploads.
Test the unsafe cases
Test an existing attachment, no matching file, two matching files, dry run, a successful upload, and an upload response without the expected identifier. The expected result is either a durable terminal status or an explicit failure. A matching implementation is not safe until it proves it can refuse an uncertain match.
Publication boundary
Do not publish voucher numbers, payout identifiers, dates, PDF filenames, financial values, Drive IDs, source URLs, endpoint paths with record IDs, credentials, tracking-table IDs, raw returned file IDs, error payloads, raw PDFs, or workflow exports.
