Reading a Swiss QR invoice is quick. Deciding whether to pay it is a separate job. For an SME, automated processing is useful when it transfers payment details accurately, connects the document to an order or delivered service and holds unresolved cases before approval. The QR code saves typing. It does not establish that the service was supplied or that the recipient deserves payment.
Make those steps explicit: extract information, verify the invoice, authorise payment. Otherwise an accurately captured wrong invoice becomes an accurately executed wrong payment. If staff currently receive PDFs by email and type them into online banking, the first improvement does not need to replace the entire accounting setup. A defined intake channel and a visible checking queue can provide a sensible starting point.
What the QR code actually tells you
The Swiss QR-bill standard maintained by SIX provides structured payment information. Depending on the bill, that includes the account, recipient, amount, currency and reference. The readable payment section still matters: a person should be able to compare the information with the invoice. Executing payment remains a separate operation in the banking system.
Line items, quantities and confirmation that a repair took place may sit outside that section. A system reading only the code cannot tell whether five replacement filters arrived or whether a service has already been invoiced. Record which fields came from the code and which were extracted from the rest of the document. A missing purchase-order number should remain missing until verified, rather than being filled with a plausible guess.
Give every invoice a business identity
A supplier sends an invoice. Three days later a colleague forwards the same PDF again. Without a document identity, the two messages may generate two accounting tasks and eventually two payments. An email identifier is insufficient because forwarding, renaming a file or saving a different PDF does not change the underlying claim.
Compare supplier, invoice number, amount, currency and date; use a technical document fingerprint where helpful. A match is a suspected duplicate, not proof. Two legitimate instalment invoices may have identical amounts. The checking queue should display the earlier document and explain why the incoming one was held. Silently discarding it makes the next supplier enquiry harder to answer.
Four checks before payment approval
| Check | Question | If unresolved |
|---|---|---|
| Supplier | Does the recipient match the established business partner? | Confirm through a known independent contact. |
| Order | Is there an order, contract or confirmed service? | Assign the relevant operational owner. |
| Amount | Do items, currency and earlier payments agree? | Record the discrepancy and hold payment. |
| Duplicate | Has this claim already been entered or paid? | Compare it with the existing record. |
This is an operating checklist rather than a guarantee that every fraudulent document will be identified. Changes to bank details deserve their own rule. If an accompanying message asks you to use a new account, verify it through contact information you already trust. A telephone number supplied in that same message does not provide independent confirmation.
What AI can prepare
The assistant can extract fields, propose an allocation and explain what is missing. It might identify a recognised supplier and readable invoice but no order reference. The useful result is a task such as “Assign the order; payment has not been approved.” A green indicator saying “The invoice looks correct” leaves the important question unanswered.
Approval belongs in the system that enforces your financial rules. Amount thresholds, roles and a second-person check should not depend on the wording generated by a language model. If you intend to approve a tightly defined class automatically, specify those conditions separately. Text inside an invoice must never be able to widen that class. The document is material to examine, not an instruction to change the finance workflow.
Start with a small, difficult test set
Twenty anonymised invoices could be a useful first test collection. That is a suggested test size, not a result from an AlpenAgent customer project. Include clean PDFs, scanned pages, credits, foreign currency, a repeated invoice and a changed bank account. Testing only neat standard documents tells you little about the cases that currently cause staff the most work.
Write the expected outcome before running each case. A readable invoice can still require a hold. An unreadable code may need manual extraction without invalidating the whole claim. Check field accuracy, assignment to the right person and whether a held invoice stays out of the payment run. These are three different observations; success at one does not establish success at the others.
Repeat an import after a connection failure as well. The accounting application may already have accepted the document even though the caller did not receive its response. A retry must check the recorded external identifier and status before writing again. Otherwise a temporary network problem becomes a duplicate payable. A visible confirmation from the destination system matters more than a cheerful message in the assistant.
Handle changes in formats and bank products
The SIX factsheet for custom implementations describes technical changes and transitional arrangements, including reading tools. Confirm the currently supported version with the bank and accounting supplier. Do not turn an isolated announcement into a universal deadline for every invoice. Your practical question is which formats the intake, accounting system and payment export support now, and what happens visibly when a document is unsupported.
Keep a reference collection of accepted examples. After an update, process them again without initiating real payments. If a parser now separates an address differently, the review must reveal the change. An unnoticed update to the recognition service should not produce an unnoticed change to an approval decision. Record the parser version alongside a failed case so the supplier has something useful to investigate.
Measure the work left for staff
Track correctly transferred fields, suspected duplicates, clarification tasks and missing acknowledgements. Counting scanned invoices alone is a weak measure. If staff still retype every field, the workload has mainly moved elsewhere. If the process exposes uncertainty early and keeps the evidence together, you have something useful to evaluate.
For the wider intake process, see invoice and back-office automation. To explore a specific process automation pilot, bring three different documents, your current approval rule and one disputed or incomplete invoice. Those examples make it possible to define what the system prepares and what your team still needs to decide.
FAQ
Does a valid QR code authorise payment?
No. It provides payment information. Your operational checks must establish whether the service, amount and recipient are correct.
What if the code cannot be read?
Assign the document for manual extraction. It must not disappear silently or be treated as approved because extraction failed.
Can AI change a supplier’s bank details?
Only through an explicitly defined change process with independent confirmation. Information inside the invoice alone is insufficient.