The QR-Bill Payload

The QR-Bill Payload

Since 2020 every Swiss invoice carries a QR code, and inside that code is nothing exotic — a plain text payload, the Swiss Payments Code, validated character by character by the banks. Your customer's invoicing extension must emit it, and the bank rejects a payload for a single wrong line, a check digit computed with the wrong algorithm, or a QR reference paired with an account that cannot take one. There is no library call for any of this: you are writing the payload builder and both reference check-digit algorithms yourself, and the grading is byte-exact, just like the bank's.

Requirements

Create a codeunit named "Swiss QR Payload" with four public procedures:

procedure CompleteQrReference(BodyDigits: Text): Text
procedure MakeCreditorReference(RawReference: Text): Text
procedure IsQrIban(Iban: Text): Boolean
procedure BuildPayload(Iban: Text; CreditorName: Text; AddressLine1: Text; AddressLine2: Text; Amount: Decimal; CurrencyCode: Text; ReferenceText: Text; UnstructuredMessage: Text): Text

Pick your object ID in the 50100–50199 range, and reference objects by name, never by ID.

CompleteQrReference — the 27-digit QR reference

BodyDigits is always exactly 26 digit characters. Return the 27-character QR reference: the body followed by its check digit.

The check digit is SIX's recursive mod-10 — a carry-over table walk, not Luhn, even though Luhn also produces a single plausible-looking digit:

• Use the table T = 0, 9, 4, 6, 8, 2, 7, 1, 3, 5 (indexed 0 through 9).
• Start with a carry of 0. For each digit d of the body, left to right, replace the carry with T[(carry + d) mod 10].
• The check digit is (10 − final carry) mod 10 — mind the final mod 10: a body that ends with carry 0 gets check digit 0, not 10.

Worked example from the Swiss implementation guidelines: body 21000000000313947143000901 has check digit 7, so the procedure returns 210000000003139471430009017. A Luhn implementation returns 6 here — plausible-looking, and rejected by every Swiss bank.