Swiss QR-Bill Requirements: What AP Teams Need to Know

Every Swiss invoice with a payment part now carries a QR code encoding 42 standardized data fields: payee name and address, payer details, payment amount, currency (CHF or EUR), and a structured payment reference. For AP teams processing Swiss invoices, these fields deliver clean, machine-readable payment data on every bill that crosses your desk. But they cover only one side of the equation.

The QR code covers payment information only. It tells your banking software where to send money, how much, and which reference number to include. What it does not contain is the data AP teams actually need for accounting workflows. Line items, quantities, unit prices, VAT rates and breakdowns, vendor tax identification numbers, purchase order references, delivery dates, and payment terms remain in the invoice body itself, outside the QR code. Processing a Swiss QR-bill invoice still means extracting that data separately, whether manually or through automated tools.

This two-part reality is a direct result of what the QR-bill was designed to do. On September 30, 2022, Switzerland retired all traditional payment slips — orange ESR, red BVR, and blue BV — and replaced them with the QR-bill, which embeds a Swiss QR Code on a standardized DIN A6 payment part. The transition, governed by SIX Group and the Swiss Payment Standards organization under the oversight of the Swiss National Bank, brought Swiss domestic payments into alignment with ISO 20022, the international financial messaging standard. Swiss payment data is now natively interoperable with global banking infrastructure, but the QR code remains a payment instruction, not a complete invoice record.

Switzerland's broader move toward digital invoicing continues to accelerate alongside the QR-bill rollout. The country's eBill platform processed approximately 70 million transactions in 2023, with over 3 million registered users covering more than half of Swiss households, according to SIX Group, the operator of Switzerland's financial infrastructure. For AP teams, though, the practical question remains: what does the QR code give you, and what still needs extraction?

What the QR Code Contains vs. What Still Needs Extraction

The Swiss QR code packs 42 discrete data fields into a single scannable payload. Here is what those fields cover — and where they stop.

Inside the QR Code: 42 Structured Data Fields

The QR code's data follows a rigid structure defined by SIX Group's implementation guidelines. The fields fall into six categories:

Category	What It Contains	Key Fields
Header	Technical metadata	QR type identifier, format version, character encoding (UTF-8)
Creditor/Payee	Who receives the payment	Account number (IBAN or QR-IBAN), creditor name, street, building number, postal code, city, country
Payment Amount	How much to pay	Amount (can be left blank for variable amounts), currency (CHF or EUR)
Debtor/Payer	Who is paying (if pre-filled)	Payer name, street, building number, postal code, city, country
Payment Reference	How to identify the payment	Reference type (QRR, SCOR, or NON), reference number
Additional Information	Free-text and structured extensions	Unstructured message field, billing information (Swico S1 parameter), trailer

Together, these fields answer the core payment question: who to pay, how much, to which account, and which reference to cite. If the debtor fields are populated, the QR code also confirms who the payer is with their structured address.

What the Invoice Body Still Contains

Here is the problem for AP teams: the Swiss QR-bill format is a payment initiation instrument, not a complete invoice record. The 42 data fields enable you to execute payment, but they do not provide the data you need for cost allocation, spend analysis, VAT compliance, or three-way matching against purchase orders and goods receipts.

Data that remains exclusively in the invoice body:

Line items and descriptions — individual products or services, quantities, unit prices, and line totals
VAT rate breakdown — separate tax amounts at different rates (8.1% standard, 2.6% reduced, 3.8% accommodation), which Swiss VAT reporting requires
Vendor tax and registration IDs — UID (Unternehmens-Identifikationsnummer) and VAT registration numbers
Purchase order references — PO numbers needed for three-way matching
Delivery dates and service periods — when goods were delivered or services rendered
Payment terms — net days, early payment discounts, and due dates (unless Swico S1 billing information is present in the QR code, covered in the next section)
Bank details beyond the payment account — correspondent bank information for international transfers
Supplementary documentation — contract references, project codes, cost center allocations

This gap is significant. Parsing the QR code gets you from invoice receipt to payment execution, but it skips the entire middle layer of AP processing where invoices are validated, coded, and reconciled. A finance team that only reads the QR code can pay the bill but cannot tell you what they paid for, which budget it hits, or whether the VAT was correctly charged.

Bridging the Gap Between QR Data and Full Invoice Processing

The structured-versus-unstructured divide is what makes Swiss QR-bill data extraction a two-part problem. The QR code gives you clean, machine-readable payment data. Everything else sits in the invoice body as unstructured text, tables, and formatting that varies by vendor.

AI-powered extraction platforms address this directly by processing both layers in a single pass. The QR code's structured payment fields are parsed alongside the unstructured invoice body — line items, VAT breakdowns, vendor details, PO references — and the result is one consolidated, structured output. Tools built for this workflow handle PDFs (both native and scanned), image files from mobile captures, and mixed-format batches, extracting header-level and line-item data regardless of the source document's quality or language. For AP teams handling volume across dozens of Swiss vendors, the ability to automate Swiss invoice data extraction across both the QR payload and the invoice body eliminates the manual reconciliation step entirely.

The QR code's additional information field does offer one partial bridge: the Swico S1 billing information parameter can carry structured VAT and payment term data inside the QR code itself. Not every invoice includes it, but when present, it narrows the extraction gap meaningfully.

Swico S1 Billing Information: VAT and Payment Terms Inside the QR-Bill

The Swico S1 record is a structured billing information format (StrdBkgInf) defined by Swico, the Swiss Software Industry Group. It lives inside the QR code's "additional information" field and carries accounting data that goes well beyond the core payment fields.

What the S1 Record Contains

The Swico S1 field packs a surprising amount of accounting-relevant data into a single structured string. When populated, it can include:

Invoice number — the biller's document reference
Invoice date — issuance date of the underlying invoice
Customer reference — typically the purchase order number, enabling automated PO matching
VAT number — the biller's Swiss UID (Unternehmens-Identifikationsnummer)
VAT date range — the service period (from/to dates) to which the VAT applies
VAT rate details — one or more rate breakdowns, each specifying the VAT percentage and the taxable amount at that rate. An invoice with items at 8.1% and items at 2.6% will carry both breakdowns in the S1 field
Payment conditions — discount percentage and the number of days within which the discount applies (e.g., 2% discount if paid within 10 days)
Total amount — the gross invoice amount

This is machine-readable data embedded directly in the QR code. No OCR, no PDF parsing, no template matching required for these fields.

The S1 data is encoded as a single delimited string using forward slashes to separate field identifiers and values. A typical S1 record reads: //S1/10/10201409/11/240401/30/106017086/31/240101240630/32/8.1:950;2.6:50/40/2:10;0:30 — where 10 denotes the invoice number, 11 the invoice date (YYMMDD), 30 the VAT number, 32 the VAT rate breakdown (rate:taxable amount), and 40 the payment conditions (discount percentage:days). Software integrators parsing this field can extract structured VAT, payment term, and invoice reference data directly from the QR code without touching the invoice PDF.

Why S1 Matters for AP Automation

The VAT breakdown is the standout element. Swiss VAT compliance requires accurate allocation of invoice amounts across applicable rates — a set of obligations covered in detail under the MWST invoice requirements defined in Art. 26 MWSTG — and extracting this from unstructured invoice PDFs is one of the more error-prone steps in automated processing. When S1 data is present, your system gets a pre-parsed, biller-verified VAT split that can feed directly into journal entries and VAT returns.

The payment conditions field is similarly valuable. Early payment discounts (Skonto) are common in Swiss business transactions, and missing a discount window because the terms were buried in invoice text has a direct cost. S1 makes discount terms programmatically accessible.

For AP teams building or configuring automation, the S1 field can meaningfully reduce the extraction burden on key accounting fields — invoice number, VAT breakdown, PO reference, and payment terms — for every invoice that includes it.

The Limitations AP Teams Must Design Around

S1 adoption is not universal across Swiss businesses. While many Swiss accounting software packages support S1 generation, not all invoicers enable it, and the depth of data varies. Some billers populate every field; others include only a partial set. There is no regulatory mandate requiring S1 inclusion — it remains a voluntary industry convention.

This creates a practical constraint: AP workflows cannot treat S1 as a guaranteed data source. Any automation pipeline processing Swiss invoices needs a fallback extraction path for invoices that arrive without S1 data or with incomplete S1 fields. The reliable approach is to use S1 as a high-confidence supplement — when present, trust it and reduce reliance on extracted values; when absent, fall back to standard extraction from the invoice document.

There is also a scope limitation. S1 provides header-level billing data, not line-item detail. You get the total VAT breakdown across rates, but not which specific products or services map to which rate. For organizations that need line-item granularity for cost allocation or project accounting, S1 supplements but does not replace invoice body extraction.

Finally, S1 is primarily a Swiss domestic convention. International businesses issuing invoices to Swiss customers will typically not include Swico S1 data in their QR-bills, even when using the Swiss QR-bill format. AP teams at multinational organizations should expect S1 coverage to correlate closely with the proportion of their Swiss vendor base that uses Swiss-developed accounting software.

QR-Bill Reference Types and QR-IBAN: A Payment Matching Guide

Every Swiss QR-bill carries one of three reference types, and the one you encounter determines how smoothly your AP reconciliation will run.

The Three Reference Types

QRR (QR-Reference) is the Swiss domestic standard and the reference type you will see most frequently on invoices from Swiss businesses. It consists of a 27-digit numeric reference that is backwards compatible with the legacy ESR reference used in the orange payment slip system. Each QRR reference is unique per invoice, making it the most reliable option for automated matching. When your AP system receives a payment confirmation with a 27-digit QRR, it can match directly to the corresponding open invoice with no ambiguity. QRR references require the creditor to use a QR-IBAN account (more on this below).

SCOR (Creditor Reference) follows the ISO 11649 international standard. It is an alphanumeric reference of up to 25 characters that always starts with "RF" followed by two check digits. Because it adheres to an international standard, SCOR is the preferred reference type for cross-border invoicing and is commonly used by Swiss businesses that invoice internationally or by foreign companies that have adopted QR-bill formatting. SCOR references can be used with either a QR-IBAN or a regular IBAN, giving creditors more flexibility in their banking setup. For AP teams processing invoices from multiple countries, SCOR references integrate well with existing reconciliation systems that already support ISO 11649.

NON (No Reference) means the QR-bill carries no structured reference at all. The creditor either does not need a reference for their own reconciliation or has chosen to rely on unstructured message fields instead. From an AP perspective, NON references are the most problematic. Without a structured identifier to match against, your team must fall back on manual matching or fuzzy logic based on amount, date, and creditor details. Invoices with NON references should be flagged for manual review in your payment workflow.

QR-IBAN vs Regular IBAN

A QR-IBAN looks like any other Swiss IBAN at first glance, but it contains a distinct institution identifier in the range 30000–31999 (the IID portion of the account number). This special identifier routes payments through the QR-bill-specific clearing process rather than standard interbank clearing.

The critical rule for AP teams: QRR references always require a QR-IBAN. If an invoice carries a QRR reference, the creditor's account will be a QR-IBAN, and your payment system must recognize and route it accordingly. Sending a QRR-referenced payment to a regular IBAN — or vice versa — will cause the payment to fail or be rejected.

SCOR and NON reference types use regular IBANs (though SCOR can also work with a QR-IBAN). In practice, your ERP or payment platform needs to detect the IID range to distinguish QR-IBANs from standard IBANs automatically, since the format difference is subtle enough to miss in manual processing.

Reconciliation Implications by Reference Type

Reference Type	Format	Automated Matching	Typical Use Case
QRR	27-digit numeric	High reliability — unique per invoice	Swiss domestic invoicing
SCOR	Up to 25 chars, starts with "RF" + check digits	Reliable — ISO standard supported by most ERP systems	International and cross-border invoicing
NON	No structured reference	Poor — requires manual review or fuzzy matching	Ad-hoc invoices, donations, simple billing

For AP teams processing high volumes of Swiss invoices, the practical takeaway is straightforward. QRR references offer the strongest foundation for straight-through processing — the 27-digit reference maps one-to-one to an open invoice and eliminates matching ambiguity. SCOR references work well within any system that supports ISO 11649 creditor references, which most modern accounting platforms do. NON references are the exception that breaks automation; build your workflow to catch and queue these for human review rather than attempting to force an automated match.

QR-Bill Version 2.3 and the Structured Address Deadline

QR-bill version 2.3 took effect in November 2025 and introduced the most operationally significant change since the format's original rollout: a mandate for structured addresses. For AP teams and software integrators, this update carries a firm compliance deadline and direct implications for how vendor data flows through payment systems.

What changed. Prior to version 2.3, QR-bills supported two address formats. The "combined" format allowed up to two free-text address lines — a sender could enter something like "Bahnhofstrasse 42, 8001 Zürich" as a single string, or split it across two lines however they chose. The "structured" format, by contrast, requires individual fields for street name, building number, postal code, city, and country. Both formats were valid, and many billers defaulted to the combined approach because it was simpler to implement.

Version 2.3 eliminates that optionality. All new QR-bill implementations must now use structured addresses exclusively. Existing systems that still generate combined addresses have a grace period, but it ends on September 30, 2026. After that date, QR-bills containing unstructured address data will no longer be accepted for processing through the Swiss payment infrastructure.

Why this matters for AP processing. The difference between structured and unstructured addresses is not cosmetic — it directly affects how reliably your systems can automate vendor matching. When an address arrives as free-text lines, your parsing logic has to guess where the street name ends and the postal code begins. Swiss addresses are relatively standardized, but "combined" fields still produce inconsistencies: abbreviations, missing building numbers, city names appended to postal codes without delimiters. Each variation is a potential mismatch against your vendor master data, requiring manual review.

Structured addresses eliminate this ambiguity. Each data element occupies its own field, so your ERP or AP automation platform can map street, postal code, and city directly to the corresponding fields in your vendor records. The result is higher straight-through processing rates and fewer false exceptions in three-way matching workflows.

The broader context. This structured data mandate aligns Switzerland's QR-bill format with ISO 20022 messaging standards, which require discrete, machine-readable data fields rather than free-text blocks. Swiss financial infrastructure has been migrating to ISO 20022 for several years, and the address standardization in QR-bills is a natural extension of that effort.

If your organization already handles global e-invoicing standards and mandates in other European markets — Italy's mandatory SDI system, Greece's myDATA e-invoicing requirements — the QR-bill structured address deadline follows the same underlying principle: machine-readable, standardized data is becoming a regulatory expectation. The parsing infrastructure you have built for those mandates may already handle structured address fields correctly.

What to do before September 2026. If your organization receives Swiss QR-bills, verify whether your current parsing handles structured address fields correctly. If your systems were built to extract addresses from combined free-text lines, they will need updating — not because the data disappears, but because the field structure changes. For teams that integrate QR-bill data into vendor master matching or automated payment workflows, testing against structured-format sample bills now avoids disruption when the grace period closes.

Automating Swiss QR-Bill Invoice Processing

Processing a Swiss QR-bill invoice involves two distinct data layers: the structured QR code payload and the unstructured invoice body. An effective workflow addresses both.

Step 1: Parse the QR code. The 42 structured payment fields give you a reliable starting point — creditor, amount, currency, reference, and payer details are all machine-readable by design.

Step 2: Extract the invoice body. This is where the heavier lift happens. Line items, quantity breakdowns, VAT detail, vendor references, purchase order numbers, and delivery information all live outside the QR code and require intelligent extraction from PDFs or scanned documents.

Step 3: Parse Swico S1 billing information when present. If the QR-bill includes S1 structured billing data in the alternative procedures field, extract the embedded VAT breakdowns by rate, payment terms, and due date calculations. This eliminates manual reconciliation of tax detail against the invoice face.

Step 4: Match payment references. Cross-reference the QR-reference (QRR), Creditor Reference (SCOR), or free-text reference against open purchase orders or expected invoices in your ERP. QRR references are unique per invoice and designed for automatic matching — use them as the primary reconciliation key when available.

Step 5: Route and execute payment. Use the extracted QR-IBAN or standard IBAN to route the payment. For QRR-referenced invoices, the QR-IBAN is mandatory and routes through the QR-IID infrastructure rather than standard SWIFT channels.

International Businesses: What to Watch For

Non-Swiss AP teams encountering Swiss QR-bill invoices face several unfamiliar elements. Swiss invoices arrive in German, French, Italian, or English depending on the issuing canton — sometimes mixing languages within a single document, similar to how Belgian invoices must follow strict regional language rules across the country's four language areas. A single month's invoice batch from Swiss vendors might include German invoices from Zurich, French invoices from Geneva, and Italian invoices from Lugano, all landing in the same processing queue without manual language selection. Teams handling these invoices need extraction capabilities that work reliably across processing invoices across multiple languages and currencies, consolidating multilingual input into standardized output fields.

Swiss franc amounts are also conventionally rounded to the nearest 0.05 CHF, which can create small discrepancies if your accounting system applies standard two-decimal rounding. Configure your reconciliation tolerances accordingly.

QR-IBAN routing can also create friction. International payment platforms may not recognize the QR-IBAN format or route payments correctly through the QR-IID system. Verify that your banking and treasury systems support QR-IBAN before processing the first payment — a standard SEPA transfer to a QR-IBAN will fail or be rejected.

Reference type handling requires attention as well. QRR references are specific to the Swiss payment infrastructure and have no direct equivalent in international payment conventions. Your AP system needs logic to distinguish between QRR, SCOR, and free-text references and apply the correct matching rules for each. SCOR references follow the ISO 11649 standard and are more familiar to international teams, but QRR remains the dominant format for domestic Swiss billing — just as Belgium's OGM-VCS structured communication system dominates Belgian domestic invoicing with its own 12-digit reference format tied to CODA bank reconciliation. Beyond reference formats, country-specific VAT rules add another layer — invoices from Dutch small businesses operating under the KOR small business VAT exemption, for example, carry no VAT at all and include a mandatory exemption statement, which AP systems must recognize rather than flag as a missing tax field.

For organizations that also receive eBill invoices through the SIX eBill network, the same reference types and QR-IBAN conventions apply — eBill simply delivers the invoice data electronically rather than as a printed or PDF document. The downstream processing logic stays the same.

From Manual Entry to Full Automation

The automation spectrum for Swiss QR-bill processing ranges widely. At the manual end, staff scan the QR code with a reader, key the extracted fields into their accounting system, then separately enter line items and tax details from the invoice body. This works for low volumes but breaks down quickly at scale.

At the automated end, the QR code is parsed programmatically while AI-driven extraction handles the invoice body — pulling line items, tax breakdowns, vendor details, and PO references without manual intervention. The QR code's structured payload gives automation a head start: 42 fields arrive pre-parsed and validated. The challenge is the invoice body, where formats vary by vendor, languages shift between documents, and scanned copies introduce image quality issues.

Batch processing becomes critical for businesses handling high volumes of Swiss invoices. A typical month might include PDF invoices from ERP systems, scanned paper invoices, and mobile phone photos of delivery receipts — all containing QR-bill payment parts that need to be processed alongside full invoice content. Invoice Data Extraction is built for exactly this scenario — mixed batches of Swiss invoices in varying formats and languages, processed through AI-driven extraction that handles both the QR code payload and the invoice body. The platform processes German, French, Italian, and English invoices without manual language configuration, and its AI engine interprets context and field relationships rather than relying on rigid OCR templates — which matters when Swiss invoice formats vary as widely as they do across vendors and cantons.