Belgium Structured Communication (OGM-VCS): A Complete Guide

A structured communication (gestructureerde mededeling in Dutch, communication structurée in French) is a 12-digit payment reference number used on Belgian invoices, displayed in the format +++XXX/XXXX/XXXXX+++. Governed by Febelfin, the Belgian Financial Sector Federation, it uses a modulo 97 check digit to enable automated matching of bank transfer payments to invoices through Belgium's CODA electronic bank statement files.

Known as OGM (Overschrijving met Gestructureerde Mededeling) or VCS (Virement avec Communication Structurée), this Belgium structured communication system is uniquely Belgian. Each OGM-VCS reference encodes a unique identifier for a specific invoice or transaction. When a payer includes this reference exactly as printed on the invoice, the recipient's bank and accounting systems can automatically match the incoming payment to the correct outstanding invoice — eliminating the manual, error-prone process of matching free-text payment descriptions to open receivables.

This guide covers how the OGM-VCS format works, how to validate and generate references, whether structured communication is legally required on Belgian invoices, the end-to-end reconciliation workflow through CODA bank statements, and how the system fits into Belgium's Peppol e-invoicing mandate.

How the +++XXX/XXXX/XXXXX+++ Format Works

Every Belgian structured communication is a 12-digit number. How it appears depends on where you encounter it.

On printed invoices and PDF documents, the reference uses a visual format designed for easy reading: three groups of digits separated by forward slashes and enclosed by triple plus signs.

+++XXX/XXXX/XXXXX+++

The three groups contain 3, 4, and 5 digits respectively. Some implementations use triple asterisks (***) instead of plus signs as delimiters — both are valid and carry identical meaning.

In electronic banking systems — CODA files, SEPA payment messages, and banking software — the same reference appears as 12 consecutive digits with no separators or delimiters. The plus signs, asterisks, and slashes are purely visual formatting aids that make the number easier for humans to read and transcribe. They carry no data significance.

Take this example:

Format	Representation
Visual (invoice)	+++090/9337/55493+++
Digital (banking)	090933755493

Both represent the same Belgian payment reference number. The underlying data is always the 12-digit string.

Breaking down the 12 digits. The structure splits into two parts:

• Digits 1–10 are the reference number itself
• Digits 11–12 are the modulo 97 check digit (covered in the next section)

In the example above, 0909337554 is the reference and 93 is the check digit.

What the first 10 digits encode. There is no mandated internal structure for these digits. The invoice issuer decides what they represent. Common approaches include:

• Invoice number — the most frequent choice, often zero-padded to fill 10 positions
• Customer account number — useful when the same customer makes recurring payments
• Sequential counter — a simple incrementing reference tied to a billing system
• Composite encoding — some businesses pack both a customer ID and invoice number into the 10 digits

The only hard constraint is that each structured communication must be unique per invoice. Beyond that, the issuer has full discretion over the encoding logic. This is why you cannot reverse-engineer what a Belgium invoice reference number format means without knowing the issuer's system — the digits could represent an invoice number, a contract reference, or an internal code that only their accounting software understands.

Modulo 97 Check Digit Validation

The last two digits of every OGM-VCS reference are not random — they are a check digit calculated using the modulo 97 algorithm. This built-in error detection catches transcription mistakes, OCR misreads, and manual entry errors before they cause payment matching failures. A single wrong digit anywhere in the reference will almost always produce a different check digit, immediately flagging the problem.

The Algorithm Step by Step

Validating a Belgium structured communication reference takes five steps:

1. Extract the 12-digit number from the formatted reference (strip the +++ delimiters and / separators).
2. Take the first 10 digits as a single integer. These are the meaningful reference digits.
3. Divide by 97 and take the remainder (the modulo operation).
4. Interpret the result:
   • If the remainder is 0, the check digit is 97.
   • Otherwise, the remainder itself is the check digit. Add a leading zero if the result is less than 10 (the check digit always occupies two positions).
5. Compare your calculated check digit against digits 11 and 12 of the reference. If they match, the reference is valid.

Worked Example

Take the reference +++123/4567/89002+++.

Strip formatting to get the 12-digit number: 123456789002.

The first 10 digits: 1234567890.

Calculate: 1,234,567,890 ÷ 97 = 12,727,504 with a remainder of 2.

The remainder is not zero, so the check digit is 02 (padded to two digits). This matches the last two digits of the reference — the structured communication is valid.

The Edge Case: Check Digit 97

When the first 10 digits divide evenly by 97, the remainder is 0. Since a check digit of "00" would be ambiguous and easy to confuse with a missing value, the convention assigns 97 as the check digit instead. The lowest valid structured communication is +++000/0000/00097+++ — ten zeros followed by check digit 97, because 0,000,000,000 mod 97 = 0.

Why This Matters in Practice

When a payment arrives with a structured communication, the receiving accounting system can validate the check digit before attempting to match the reference against open invoices. If the modulo 97 check fails, the system knows the reference was corrupted during transmission — whether by a keying error at the bank, an OCR misread on a scanned payment slip, or a copy-paste mistake. The payment gets flagged for manual review rather than silently failing to match, preventing reconciliation errors from propagating through the ledger.

Generating a Structured Communication

Creating an OGM-VCS reference is the reverse of validation:

1. Choose a 10-digit reference number. This is typically derived from your invoice number, customer account number, or a sequential counter. Pad with leading zeros if your number is shorter than 10 digits.
2. Calculate the modulo 97 check digit using the algorithm above.
3. Append the check digit to produce the full 12-digit structured communication.
4. Format for display by adding the +++ delimiters, slashes, and digit grouping: +++XXX/XXXX/XXXXX+++.

Most Belgian accounting software and ERP systems generate structured communications automatically when creating invoices. For custom implementations or integrations, the process above is all that is needed.

---

Is Structured Communication Mandatory on Belgian Invoices?

No. Structured communication is not a legal requirement under Belgian invoice legislation. Belgian VAT law (the Code de la TVA / BTW-Wetboek) defines specific mandatory fields for invoices — VAT identification numbers, invoice date, line item descriptions, taxable amounts, applicable VAT rates — but the OGM-VCS reference is not among them. No Belgian statute or regulation compels a business to generate or include a structured communication on its invoices.

So what is it, exactly? The OGM-VCS is a banking convention maintained by Febelfin, the Belgian Financial Sector Federation. Febelfin is the umbrella organization representing Belgian banks and financial institutions, and it defines the structured communication standard that every Belgian bank supports in its payment processing infrastructure. When a payment carries a valid +++XXX/XXXX/XXXXX+++ reference, the receiving bank can pass it through to the beneficiary's account statements in a machine-readable format. This is an industry standard, not a government mandate.

Despite its voluntary status, adoption is virtually universal among Belgian businesses. The reconciliation benefit is too significant to forgo. A company that issues invoices without structured communication forces itself into manual payment matching — scanning free-text references, cross-checking amounts against open receivables, and chasing unidentified payments. For any business processing more than a handful of invoices per month, this is an unacceptable overhead. The Febelfin structured communication standard exists precisely because automated matching at scale demands a consistent, validated reference format.

For international companies invoicing Belgian customers, the practical guidance is straightforward: include a structured communication even though it is not legally required. Belgian businesses expect it. Their accounting software — whether it is a major ERP system or a local Belgian package — is configured to ingest structured references from bank statements and match them to open invoices automatically. An invoice arriving without one will likely be processed, but it introduces friction and delays on the recipient's side that can affect your payment timelines.

For companies paying Belgian suppliers, the critical detail is how you enter the reference. When a Belgian invoice includes a structured communication, enter it in the structured communication field of the bank transfer — not the free-text message field. Belgian banks route these two fields differently. A valid OGM-VCS entered in the free-text field will not trigger automated matching on the supplier's end, which defeats the entire purpose. Most online banking platforms for SEPA transfers present both options; select the structured format and input the digits exactly as shown on the invoice.

---

From Invoice to Payment: The OGM-VCS Reconciliation Workflow

Here is the complete lifecycle of an OGM-VCS payment, from invoice creation to automatic cash allocation.

1. The invoice issuer generates a unique OGM. When creating an invoice, the issuer's billing or ERP system produces a structured communication code. The first 10 digits typically encode the invoice number, customer reference, or another internal identifier. The system then calculates the modulo 97 check digit and appends it, producing the full 12-digit OGM.

2. The OGM is printed on the invoice. The code appears in its standard +++XXX/XXXX/XXXXX+++ format, usually positioned near the bank account number and payment amount. This tells the payer exactly what to enter when making the transfer.

3. The payer initiates a SEPA bank transfer. When paying the invoice, the payer enters the OGM in the structured communication field of their banking application. This is a dedicated field, distinct from the free-text communication box, and it enforces the 12-digit format with automatic check digit validation before submission. Because the structured communication field is part of the SEPA payment standard, this works across all Belgian banks and extends to cross-border transfers — a company in the Netherlands or Germany paying a Belgian supplier uses the same standardized field.

4. The banking system preserves the OGM as payment metadata. As the payment moves through the SEPA clearing network, the structured communication travels with it as standardized metadata. It is not truncated, reformatted, or stripped out during processing.

5. The recipient's bank records the OGM in the electronic bank statement. When the payment settles, the OGM appears in the recipient's CODA file — Belgium's standard electronic bank statement format. The code is stored in a fixed, machine-readable field, making extraction trivial for any software that parses CODA.

6. Accounting software matches the payment to the open invoice. The recipient's accounting or ERP system reads the CODA file, extracts the OGM from each incoming transaction, and looks it up against outstanding invoices. A match triggers automatic reconciliation — the invoice is marked as paid, the ledger is updated, and no human touches the transaction.

The result is fully automated accounts receivable reconciliation with zero manual intervention. Every payment that carries a valid OGM can be matched to its invoice instantly and without ambiguity.

Compare this to what happens without structured communication. Payments arrive with free-text descriptions — "payment for invoice 2024-001," "January services," or sometimes nothing at all. AP and AR teams must then manually search open invoices, interpret vague references, and handle partial payments or combined payments by guesswork. This is slow, error-prone, and breaks down entirely at volume. Organizations processing hundreds or thousands of Belgian payments per month cannot sustain manual matching. Automated invoice reconciliation workflows built on structured communication scale without adding headcount.

---

CODA Files: Belgium's Electronic Bank Statement Standard

CODA — short for Coded Statement of Account — is Belgium's standard format for electronic bank statements. While most countries rely on international formats like MT940 or CAMT.053 (ISO 20022), Belgian banks developed CODA specifically around domestic banking conventions. That design choice has a direct consequence for payment processing: CODA files include native, dedicated fields for structured communications.

Every major Belgian bank provides CODA files through its online banking platform. Businesses can download them daily or on demand, and most banks support automatic delivery to a designated mailbox or integration endpoint. The files contain a complete record of account transactions — debits, credits, balances — encoded in a fixed-width text format that accounting software can parse without ambiguity.

The link between CODA and OGM-VCS is what makes automated reconciliation work in practice. When a customer pays an invoice using the structured communication printed on it, the bank records that reference in a specific field within the CODA file. Accounting software reads the file, extracts each payment's OGM-VCS reference, and matches it against open invoices. No manual lookup, no guesswork about which payment covers which invoice.

Belgian accounting packages treat CODA import as a core feature rather than an optional add-on. The major platforms with built-in CODA support and OGM matching include:

• Octopus — widely used by Belgian accountancy firms
• Exact Online — cloud-based, popular with SMEs
• Yuki — automated document processing with CODA integration
• BOB50 (now Sage BOB 50) — long-standing Belgian accounting software
• WinBooks — another Belgian market staple with native CODA handling

Each of these systems can ingest a CODA file and automatically propose matches between incoming payments and outstanding invoices based on the structured communication field.

CODA's persistence in Belgian accounting — despite the availability of internationally standardized formats — reflects a practical reality. MT940 and CAMT.053 handle cross-border transactions well, but they were not built around Belgian structured communications. CODA was. For domestic payment processing where OGM-VCS references are the primary matching key, CODA files carry that data in a cleaner, more predictable structure than generic international formats.

For businesses operating in Belgium or processing Belgian transactions, understanding CODA is not optional. It is the mechanism through which bank transaction data flows into accounting systems. Anyone analyzing bank statement data for reconciliation in a Belgian context will encounter CODA files as the default starting point, and configuring their software to import and parse them correctly is one of the first steps in establishing efficient Belgian payment operations.

---

OGM-VCS and Belgium's Peppol E-Invoicing Mandate

Belgium mandated B2B e-invoicing via the Peppol network starting January 2026 for domestic transactions between VAT-registered businesses. This shift raises a practical question for finance teams: does Peppol replace the OGM-VCS system, or do the two coexist?

They serve entirely different functions. Peppol governs how an invoice is delivered. OGM-VCS governs how the resulting payment is identified. An electronic invoice transmitted through the Peppol network still requires a payment reference that the recipient's bank and accounting system can use to match the incoming funds to the correct open receivable. The structured communication fills exactly that role.

In technical terms, Peppol BIS 3.0 invoices use the UBL (Universal Business Language) XML format. Within this format, the PaymentMeans/PaymentID field carries the structured communication reference. When a Belgian supplier issues a Peppol e-invoice containing +++120/4564/23192+++, the buyer's AP system extracts that reference from the PaymentID field and passes it through to the payment instruction — preserving the same automated reconciliation workflow that has operated for decades via paper and PDF invoices.

The scale involved makes this interoperability essential. According to studies ordered by the Belgian Federal Public Service for Administrative Simplification (FPS BOSA), approximately one billion invoices are exchanged in Belgium each year, and converting them to structured electronic invoices is expected to generate savings of at least EUR 3.5 billion per year, as documented in OpenPeppol's country profile for Belgium. Processing that volume without automated payment matching would be operationally impossible. OGM-VCS is the mechanism that keeps reconciliation running at scale, regardless of whether the invoice itself arrives electronically or on paper.

Belgium is not alone in maintaining a standardized payment reference system alongside modern e-invoicing infrastructure. Other countries have developed their own solutions to the same fundamental problem of matching payments to invoices automatically. Finland uses a similar structured reference number with a check digit, and Switzerland's QR-bill payment standard embeds a complete structured payment reference directly into a machine-readable code on every invoice. These systems all reflect the same underlying reality: e-invoicing standards handle document exchange, but the payment leg of the transaction still needs a reliable, machine-readable identifier.

Whether an invoice arrives as a paper document, a PDF attachment, or a Peppol BIS 3.0 e-invoice, the +++XXX/XXXX/XXXXX+++ reference printed or embedded within it continues to serve the same core function it has since its introduction: enabling banks and accounting software to match payments to invoices without manual intervention. Belgium's move to mandatory e-invoicing does not diminish the role of OGM-VCS. It reinforces it — by ensuring that every B2B invoice now carries a structured, machine-readable format end to end, from issuance through delivery to payment reconciliation.