Review payment references as structured information

A payment document can look familiar while containing a reference that the receiving system cannot reconcile. In a fictional invoice project, the important question is not merely whether a QR image scans. It is whether the document carries the correct account, currency, reference and invoice relationship under the applicable arrangement.

Work from the current specification

Where Swiss QR-bills are in scope, use SIX's current guidelines and confirm the supporting bank or provider interface. Record the version and the permitted field combinations. Do not infer provider eligibility or the legal correctness of an invoice from a generated image.

Keep invoice identity separate from payment notification identity. The accounting owner decides how partial payments, corrections and unmatched amounts are handled. The application should show the evidence and operator action rather than changing an outstanding balance on the basis of an unrelated notification.

Review forms with meaningful examples

Use fictional references that preserve leading characters and zeros where their format requires them. Copy a value from a document into the form and export it again. Check that display formatting has not altered the stored identity. Label the expected input and explain corrections without discarding the rest of the user's work.

Reconcile a difficult case

Test a repeated event, a partial payment and an unknown reference in suitable private facilities. Staff should identify what was billed, what evidence arrived and what remains unresolved. No real payment is needed for this planning exercise. Read invoice integrations before committing to the scope.

Worked example: a payment belongs to the other invoice

Consider two fictional invoices, I-612 and I-621, each with an amount of CHF 480.00. A provider-supported record confirms a payment of CHF 480.00 carrying the reference associated with I-621. An operator looking only at the amount could close I-612 incorrectly. Equal totals do not establish equal identity.

The review fixture should include the invoice reference, customer relationship, currency, issued document and payment evidence. The finance owner approves how reconciliation is performed. A view that merely highlights the first matching amount is inadequate when another invoice has the same total.

Ask the operator to explain why the payment applies to I-621 and what remains outstanding on I-612. If the available evidence cannot establish that relationship, the result should remain unresolved. The interface should not choose a customer on the basis of a similar name or a convenient row order.

Keep document validation separate from reconciliation

A QR-bill project has at least two different questions. Does the issued document conform to the applicable supported format? Does later evidence belong to the intended invoice and justify the chosen accounting action? Successfully scanning a code cannot answer both.

Use the current SIX specification and provider-supported validation to establish the relevant document checks. Record the actual supported account/reference arrangement rather than inserting a remembered format into every invoice. Technical validation and the finance team's reconciliation policy remain distinct evidence.

For a correction, introduce a provider record with an unknown reference and the same CHF 480.00 amount. The application should provide an investigation path. It should not close either invoice simply to eliminate an unmatched item. Include a repeated notification for the already confirmed payment; whether the provider repeats a message or staff reload the page must not create a second independent receipt.

The fixture uses invented identifiers and no bank account or real payment. Its purpose is to test whether the operator can identify the document, source evidence and remaining action. It does not certify an invoice's legal treatment, demonstrate bank acceptance or establish availability of a payment interface to a particular account.