Sweden Bankgiro & OCR Number Invoice Payment Guide

If you handle invoices from Swedish vendors, you've probably noticed something unusual: where you'd expect an IBAN, you instead find a 7-8 digit Bankgiro number. Sweden's domestic payment infrastructure predates SEPA and IBAN standardization, and for the vast majority of Swedish business-to-business transactions, Bankgiro numbers remain the primary payment identifier on invoices. Understanding how this system works isn't optional for anyone processing, extracting, or reconciling Swedish invoice payment data.

Bankgiro is a payment routing system operated by Bankgirot, Sweden's central clearing house for mass payments. Each Bankgiro number identifies a specific payee account and directs funds through the Bankgiro clearing network rather than through IBAN-based SEPA transfers. Bankgirot processes more than SEK 80 billion in payments every day, handling the flow of funds between banks, businesses, and individuals across the country. That volume reflects how deeply embedded the system is in Swedish commerce. A parallel system called PlusGiro, historically tied to postal banking, serves the same function and appears on invoices in the same way.

Why does Sweden diverge from the IBAN standard that dominates the rest of Europe? The Bankgiro system has been operational since 1959, decades before SEPA existed. Swedish banks and businesses built their payment workflows, ERP integrations, and reconciliation processes around Bankgiro and PlusGiro numbers. While IBAN is used for cross-border payments into and out of Sweden, domestic invoicing between Swedish companies overwhelmingly relies on these local identifiers. For AP teams accustomed to extracting IBAN and BIC/SWIFT codes from vendor invoices, Swedish invoices require a different extraction logic entirely.

Three elements on a Swedish invoice are critical to get right. The first is the Bankgiro or PlusGiro number, which tells your bank where to send the payment. The second is the OCR reference number, a 3-25 digit code validated using the Mod 10 (Luhn) algorithm that enables the receiving company's system to automatically match your payment to the correct invoice. The third is the structured invoice layout defined by Swedish standard SS 61 41 14, which dictates where these identifiers appear on the page. Each of these elements plays a specific role in ensuring that payments are routed correctly and reconciled without manual intervention.

This guide covers all three in detail: format rules, validation logic, and the practical considerations that matter when you're building extraction workflows or reconciling Swedish payment data at scale.

Bankgiro and PlusGiro Numbers on Swedish Invoices

Bankgiro Numbers: Format and Function

A Bankgiro number is a 7- or 8-digit identifier assigned to a payee organization, used to route payments through Sweden's Bankgiro clearing system. When a payer initiates a transaction through their bank, the Bankgiro number directs the funds to the correct recipient account without the payer needing to know the recipient's underlying bank account details.

The system has been in continuous operation since 1959, making it one of Europe's longest-running automated payment clearing networks. It is operated by Bankgirot (formally Bankgirocentralen BGC AB), an entity owned collectively by Sweden's major banks. Bankgirot handles the daily clearing and settlement of Bankgiro transactions, while the Riksbank, Sweden's central bank, provides oversight of the broader financial infrastructure that underpins these transfers.

On a Swedish invoice, the Bankgiro number typically appears in a clearly labeled field within the payment information section, often preceded by "Bankgiro" or abbreviated as "Bg." The number may be printed with or without a hyphen before the final digit (for example, 1234-567 or 12345678), but both representations refer to the same account.

PlusGiro: The Parallel System

PlusGiro is a second domestic payment routing system that predates much of Sweden's modern banking infrastructure. Originally operated by PostGirot as part of the Swedish postal banking network, PlusGiro is now a subsidiary of Nordea, one of the Nordic region's largest financial groups.

A PlusGiro number serves the same function on an invoice as a Bankgiro number: it identifies the payee's clearing account so that the payer's bank can route the payment correctly. The key difference is institutional, not functional. Some Swedish businesses maintain both a Bankgiro number and a PlusGiro number, and invoices from these companies may list both options in the payment details section. When both are present, either can be used to complete the payment.

For AP teams processing Swedish invoices, the practical implication is straightforward: extract whichever identifier the invoice provides, confirm it matches the vendor's records, and use it as the payment destination.

How Bankgiro and PlusGiro Differ from IBAN

If you are accustomed to IBAN-based invoices from other European countries, the presence of Bankgiro or PlusGiro numbers instead of (or alongside) an IBAN can be initially confusing. The distinction is important:

Bankgiro and PlusGiro numbers identify a payee's clearing account within Sweden's domestic payment systems. They are used for SEK-denominated transfers processed through Bankgirot or the PlusGiro network.
IBAN (International Bank Account Number) identifies a specific bank account for cross-border or international transfers under the SEPA framework.

Swedish invoices sent to domestic payers will almost always use a Bankgiro or PlusGiro number as the primary payment identifier. When the payee expects international payments, the invoice may also include an IBAN and SWIFT/BIC code. But for standard domestic transactions, the Bankgiro or PlusGiro number remains the default routing mechanism.

This pattern is not unique to Sweden. Many countries maintain domestic payment standards that differ from international formats. Switzerland's QR-bill payment standard for invoices is another example where a country-specific payment structure appears on invoices alongside or instead of IBAN details. For organizations processing invoices across multiple countries, each of these national conventions requires its own extraction and validation logic.

What This Looks Like on an Actual Invoice

A typical Swedish invoice presents its payment details in a grouped block, usually near the bottom of the document or in a dedicated payment information panel. The standard fields in this block include:

Bankgiro or PlusGiro number (the payment destination)
OCR reference number (the payment reference the payer must include)
Förfallodatum (payment due date)
Att betala (amount due)

The payer takes the Bankgiro or PlusGiro number and the OCR reference number and enters both when initiating payment through their bank's online platform or ERP payment module. The Bankgiro number tells the system where the money goes; the OCR reference tells the recipient which invoice the payment covers. Missing or transposing either value creates reconciliation failures on the recipient's side, which is why accurate extraction of both identifiers from the invoice is essential for automated payment workflows.

How OCR Reference Numbers Work on Swedish Invoices

The OCR reference number is a structured numeric code, between 3 and 25 digits long, printed on Swedish invoices for one specific purpose: automated payment-to-invoice reconciliation. The abbreviation OCR stands for Optical Character Recognition, a holdover from the system's origins in machine-readable payment slips processed by Swedish banks.

Here is how the mechanism works in practice. When you pay a Swedish invoice, you enter two pieces of information: the supplier's Bankgiro number (identifying who gets paid) and the OCR reference number (identifying what the payment is for). The Bankgiro clearing system passes that reference through to the payee's bank. On the receiving end, the supplier's accounting system compares the OCR reference attached to the incoming payment against the reference on the original invoice. A match means the payment is reconciled automatically — no human intervention required.

This is why the OCR reference is the single most important field for downstream processing when you extract data from Swedish invoices. An incorrect, truncated, or missing OCR reference breaks the automated matching chain and forces manual reconciliation on the supplier's side. A typical OCR reference might look like 7654321894, where the final digit (4) is the Mod 10 check digit calculated from the preceding nine digits.

The Four OCR Control Levels

Swedish businesses configure an OCR control level with their bank, which determines how strictly the system validates the reference number before accepting a payment. There are four levels, each adding a layer of validation.

OCR 1 — Soft check digit. The reference includes a Mod 10 check digit, but the bank does not reject payments when the check digit is invalid. Payments with garbled references go through and land in the supplier's account without automatic matching. This level offers the least protection against transcription errors.

OCR 2 — Hard check digit. The bank validates the Mod 10 check digit and rejects payments where the reference fails validation. This catches the most common data entry mistakes — transposed digits, single-digit errors — before the payment enters the system. The payer is forced to correct the reference and resubmit.

OCR 3 — Hard check digit plus variable length check. In addition to Mod 10 validation, the bank verifies that the reference falls within a defined length range (for example, between 8 and 12 digits). This prevents both digit errors and references that are clearly too short or too long.

OCR 4 — Hard check digit plus fixed length check. The strictest level. The bank validates the Mod 10 check digit and confirms that the reference is exactly the required number of digits. No variation is permitted.

Higher control levels reduce the volume of payments that arrive without a valid reference, which directly reduces manual reconciliation work. Businesses with high invoice volumes — where even a small percentage of unmatched payments creates significant administrative overhead — typically operate at OCR 3 or OCR 4.

How Mod 10 Validation Works

The check digit at the end of every OCR reference is calculated using the Mod 10 algorithm, also known as the Luhn algorithm. This is the same validation method used for credit card numbers worldwide.

The process works from right to left across the reference digits (excluding the check digit itself). Every second digit is doubled. If doubling produces a number greater than 9, the two resulting digits are added together (for example, 8 × 2 = 16, and 1 + 6 = 7). All values are then summed. The check digit is whatever value, when added to that sum, produces a total divisible by 10.

This algorithm is specifically designed to catch the two most frequent human transcription errors: single-digit mistakes (typing a 3 instead of a 5) and adjacent transposition errors (typing 73 instead of 37). Both errors will almost always produce a failed Mod 10 check, flagging the problem before the payment is processed.

For AP teams extracting OCR references from Swedish invoices, Mod 10 validation serves as a built-in data quality check. If an extracted reference fails Mod 10, the extraction is likely incorrect and should be reviewed before the payment is submitted.

Swedish Invoice Layout Requirements Under SS 61 41 14

Swedish invoices follow a national layout standard that most other countries simply do not have. SS 61 41 14, published by the Swedish Standards Institute (SIS), defines exactly where payment information fields should appear on an invoice. This matters because it turns Swedish invoices into something closer to a structured form than a freeform document, making the job of locating and extracting payment data significantly easier.

The standard exists for a practical reason. When every invoice places the Bankgiro number, OCR reference, amount due, and payment due date in the same predictable locations, both automated scanning systems and human processors can find what they need without hunting across the page. Before standardization, payment errors from misread fields were a constant problem in high-volume invoice processing. SS 61 41 14 addressed this by specifying precise box placements for each critical field.

The payment information block sits at the bottom of a conforming Swedish invoice, arranged in a structured layout designed to align with bank payment slip formats. This block contains four core fields:

Bankgiro or PlusGiro number — the destination account for payment
OCR reference number — the structured reference that ties the payment back to the invoice
Amount due — the total to be paid, including VAT
Payment due date — the date by which payment is expected

This bottom-of-invoice placement is deliberate. It mirrors the layout of the traditional Swedish payment slip (inbetalningskort), which banks and payment systems were already built to process. Even as paper slips have given way to electronic transfers, the positional convention persists on printed and PDF invoices.

Invoice number formatting also falls under the standard's scope. Invoice numbers should appear in the top right area of the invoice, stay under 9 characters, and avoid leading zeros, dashes, or spaces. These constraints are not arbitrary. Leading zeros can be stripped by some banking systems, dashes and spaces create ambiguity when numbers are keyed manually, and longer numbers increase the risk of transcription errors. Keeping invoice numbers short and clean supports both automated processing and manual data entry.

For anyone extracting Swedish invoice payment details, the standardized layout is a genuine advantage. Field positions on conforming invoices are predictable, which means extraction templates and parsing rules can be built with higher confidence than for invoices from countries where layout is entirely at the issuer's discretion. You can reasonably expect the Bankgiro number and OCR reference to appear in the same region of the document across different Swedish vendors.

That said, conformance is not universal. Larger Swedish companies and those using domestic accounting software like Fortnox, Visma, or Björn Lundén almost always produce invoices that follow SS 61 41 14 closely. Smaller businesses, freelancers, and companies using international invoicing platforms may deviate from the standard layout, placing payment fields in non-standard positions or omitting the structured payment block entirely. If you process invoices from a mix of Swedish suppliers, expect most to conform but plan for exceptions.

Automated Payment Reconciliation Using OCR Numbers

The real payoff of Sweden's OCR reference system is what happens after the invoice is sent. Bankgirot offers a service called Bankgiro Receivables (Bankgiroinbetalningar) that delivers structured payment data to payees, closing the loop between invoice issuance and cash application without manual intervention.

The reconciliation workflow follows a predictable sequence:

Invoice issuance. A business generates an invoice containing a unique OCR reference number and its Bankgiro number. The OCR reference encodes enough information to identify the specific invoice, customer, or transaction.
Payment submission. The payer enters the Bankgiro number and OCR reference when initiating the payment through their bank, whether via online banking, a mobile app, or a batch payment file.
Clearing through Bankgirot. The payment is routed through Bankgirot's centralized clearing infrastructure, where the OCR reference travels with the transaction data.
Receivables report delivery. The payee receives a Bankgiro Receivables file containing the payment amount, payment date, payer reference, and the OCR number attached to each transaction. These files arrive in structured formats that accounting and ERP systems can ingest directly.
Automated matching. The payee's accounting system reads the OCR reference from the receivables file and matches it against open invoices. When a match is found, the invoice is marked as paid and the ledger updates automatically.

This end-to-end flow means that a company issuing thousands of invoices per month can reconcile the vast majority of incoming payments without a human reviewing individual transactions. The OCR reference is the key that makes each step machine-readable.

When Reconciliation Breaks Down

The system works only as well as the data entering it. If a payer enters an incorrect OCR reference, transposes digits, or omits the reference entirely, the payment arrives without a usable identifier. The check digit catches many input errors at the bank's end, but payments that slip through with a wrong or missing reference land in a manual reconciliation queue.

These unmatched payments are the primary cost driver that the OCR system exists to eliminate. Each one requires someone to investigate the payment, cross-reference amounts and dates against outstanding invoices, contact the payer if necessary, and manually record the match. At scale, even a small percentage of failed matches creates significant administrative overhead.

Note that Autogiro, Sweden's pull-based direct debit system, operates differently. With Autogiro, the payee initiates collection directly from the payer's bank account under a standing mandate, so OCR references are not involved. Approximately 80% of Swedes have at least one active Autogiro mandate, but this mechanism serves recurring payments (utilities, insurance, subscriptions) rather than the push-based invoice payment flow where payers enter OCR references.

OCR as the Critical Extraction Field

For organizations extracting structured data from invoices across multiple countries, Sweden's OCR reference number is the field that links an invoice document to its corresponding payment event. Without accurate extraction of this field, automated reconciliation against Bankgiro Receivables data is not possible, and payments fall back to manual matching.

Validation matters as much as extraction. Because the OCR number includes a Mod 10 check digit, any extraction pipeline can verify that a captured OCR reference is arithmetically valid before passing it downstream. A failed check digit calculation is a clear signal of a misread or truncated value, catching errors before they cause reconciliation failures.

Sweden's broader financial compliance infrastructure extends beyond payment systems. Sweden's SIE accounting data format governs how accounting records are structured and exchanged, forming another layer of the standardized data ecosystem that makes Swedish financial operations particularly amenable to automation.

2025-2026 Bankgiro Modernization and Its Impact on Invoicing

Sweden's Bankgiro infrastructure is undergoing a series of updates designed to bring domestic payment processing closer to European and international standards. Bankgirot has been working to ensure interoperability with SEPA frameworks and to support evolving cross-border payment requirements, while preserving the core domestic system that Swedish businesses rely on daily. For anyone processing Swedish invoices, these changes introduce specific new requirements that affect how invoice data must be captured, validated, and transmitted.

The most significant near-term change takes effect in 2026: the payee's name becomes a mandatory field for Bankgiro and PlusGiro payments. Previously, a payment could be routed using only the Bankgiro or PlusGiro number and the OCR reference. Under the new requirement, invoices must clearly display the registered payee name associated with the Bankgiro or PlusGiro account, and payment systems will validate this field before processing. If the payee name is missing, incomplete, or does not match the name registered to that Bankgiro number, the payment may be rejected.

This has direct consequences for invoice formatting and data extraction workflows:

Invoice templates need updating. Any invoice that omits the payee name or uses a trading name, abbreviation, or informal business name rather than the officially registered name risks triggering validation failures. Suppliers should verify that the name printed on their invoices matches exactly what Bankgirot has on file for their account.
AP systems must capture the payee name field. Automated extraction pipelines that currently pull only the Bankgiro number, OCR reference, and amount will need to add payee name extraction. This field then needs to be included in payment file submissions.
Validation logic may need expansion. Organizations with higher automation maturity may want to cross-reference the extracted payee name against the registered name for that Bankgiro number, catching mismatches before payment submission rather than after rejection.

The broader trajectory here is convergence. Sweden's payment infrastructure is gradually aligning with European standards, which means Swedish invoices will increasingly share structural elements with SEPA-standard invoices, including mandatory creditor identification fields. However, this is not a replacement. The Bankgiro and OCR number system remains the primary domestic payment mechanism, and there is no indication that Sweden plans to abandon it in favor of pure SEPA credit transfers for domestic use. What is happening is a layering of additional validation requirements on top of the existing system.

For organizations that process invoices from multiple countries, this convergence is broadly positive. It means fewer Sweden-specific exceptions in your processing logic over time, even if the underlying payment rails remain distinct. For those focused exclusively on Swedish invoices, the key action is straightforward: ensure your systems and templates include the registered payee name as a required field before the 2026 deadline.