# Belgium (`BE`)

Ordinary Belgian receipts and invoices use the canonical receipt fields and
need no `jurisdictionalData`. Use a GKS regime only when a registered
cash-register flow actually applies.

Cheqi does not calculate, invent, or validate GKS values. The POS completes the
registered-system operation first and places the returned values in the slots
below. The receipt engine preserves them in CHEQI JSON and references them in
the generated UBL documents.

## Legacy GKS

Use `BE_GKS` for the legacy registered cash-register flow.

| Value supplied by the legacy system | Cheqi request location |
|  --- | --- |
| Cash-register serial | `jurisdictionalData.fiscalization.cashRegisterId` |
| Fiscal Data Module serial | `jurisdictionalData.fiscalization.fiscalDeviceId` |
| Fiscal receipt number | `jurisdictionalData.fiscalization.fiscalDocumentNumber` |
| Ticket/event sequence | `jurisdictionalData.fiscalization.sequenceNumber` |
| Fiscal timestamp | `jurisdictionalData.fiscalization.timestamp` |
| Short authentication value | `jurisdictionalData.fiscalization.verificationCode` |
| Opaque signature, when returned separately | `jurisdictionalData.fiscalization.signature` |
| VSC card identifier | `jurisdictionalData.additionalFields` with code `BE:VSC_ID` |
| Required visible heading for a normal VAT ticket | `jurisdictionalData.legalTexts[]` with code `BE:GKS_DOCUMENT_HEADING` and `displayRole = DOCUMENT_HEADING` |
| Exact printed control data | `jurisdictionalData.additionalFields` with code `BE:CONTROL_DATA` |
| Machine-readable verification value | Top-level `barcodes[]` |


```json
{
  "barcodes": [
    {
      "type": "QR_CODE",
      "data": "<exact verification payload produced by the legacy system>",
      "label": "GKS verification"
    }
  ],
  "jurisdictionalData": {
    "countryCode": "BE",
    "regime": "BE_GKS",
    "regimeVersion": "2026-07",
    "fiscalization": {
      "system": "BE_GKS",
      "status": "FISCALIZED",
      "fiscalDocumentNumber": "<exact fiscal receipt number>",
      "fiscalDeviceId": "<exact FDM serial>",
      "cashRegisterId": "<exact cash-register serial>",
      "sequenceNumber": "<exact ticket or event sequence>",
      "verificationCode": "<exact authentication value>",
      "signature": "<exact opaque signature, when supplied>",
      "timestamp": "<exact fiscal timestamp>"
    },
    "legalTexts": [
      {
        "code": "BE:GKS_DOCUMENT_HEADING",
        "text": "BTW-KASTICKET",
        "languageCode": "nl-BE",
        "displayRole": "DOCUMENT_HEADING"
      }
    ],
    "additionalFields": [
      {
        "code": "BE:VSC_ID",
        "value": "<exact VSC identifier>"
      },
      {
        "code": "BE:CONTROL_DATA",
        "value": "<exact control data printed by the system>"
      }
    ]
  }
}
```

For a normal Dutch-language VAT ticket, supply `BTW-KASTICKET`. For a normal
French-language VAT ticket, replace that legal-text object with:

```json
{
  "code": "BE:GKS_DOCUMENT_HEADING",
  "text": "TICKET DE CAISSE T.V.A.",
  "languageCode": "fr-BE",
  "displayRole": "DOCUMENT_HEADING"
}
```

The merchant's registered POS must select and return the legally applicable
language and document type. Cheqi preserves the supplied value; it does not
translate it or decide that a normal VAT ticket applies. Omit optional
properties that the legacy system does not return. Do not replace them with
invented values.

## GKS 2.0

Use `BE_GKS_2` after the GKS 2.0 POS has received a successful `SignResult`
from the Fiscal Data Module.

| GKS 2.0 value | Cheqi request location |
|  --- | --- |
| `posFiscalTicketNo` | `jurisdictionalData.fiscalization.fiscalDocumentNumber` |
| `posId` | `jurisdictionalData.fiscalization.cashRegisterId` |
| `terminalId` | `jurisdictionalData.additionalFields` with code `BE:TERMINAL_ID` |
| `deviceId` | `jurisdictionalData.additionalFields` with code `BE:INPUT_DEVICE_ID` |
| `fdmRef.fdmId` | `jurisdictionalData.fiscalization.fiscalDeviceId` |
| `fdmRef.fdmDateTime` | `jurisdictionalData.fiscalization.timestamp` |
| `fdmRef.eventLabel` | `jurisdictionalData.additionalFields` with code `BE:EVENT_LABEL` |
| `fdmRef.eventCounter` | `jurisdictionalData.fiscalization.sequenceNumber` |
| `fdmRef.totalCounter` | `jurisdictionalData.additionalFields` with code `BE:TOTAL_COUNTER` |
| `shortSignature` | `jurisdictionalData.fiscalization.verificationCode` |
| `digitalSignature` | `jurisdictionalData.fiscalization.signature` |
| Signature algorithm label, when supplied | `jurisdictionalData.fiscalization.signatureAlgorithm` |
| `verificationUrl` | `jurisdictionalData.fiscalization.verificationUrl` and top-level `barcodes[]` |
| Required visible heading for a normal VAT ticket | `jurisdictionalData.legalTexts[]` with code `BE:GKS_DOCUMENT_HEADING` and `displayRole = DOCUMENT_HEADING` |
| Ordered `footer[]` lines | `jurisdictionalData.legalTexts[]`, one entry per line |


```json
{
  "barcodes": [
    {
      "type": "QR_CODE",
      "data": "<exact verificationUrl returned by the FDM>",
      "label": "GKS 2.0 verification"
    }
  ],
  "jurisdictionalData": {
    "countryCode": "BE",
    "regime": "BE_GKS_2",
    "regimeVersion": "2026-07",
    "fiscalization": {
      "system": "BE_GKS_2",
      "status": "FISCALIZED",
      "fiscalDocumentNumber": "<exact posFiscalTicketNo>",
      "fiscalDeviceId": "<exact fdmRef.fdmId>",
      "cashRegisterId": "<exact posId>",
      "sequenceNumber": "<exact fdmRef.eventCounter>",
      "verificationCode": "<exact shortSignature>",
      "signature": "<exact digitalSignature>",
      "verificationUrl": "<exact verificationUrl>",
      "timestamp": "<exact fdmRef.fdmDateTime>"
    },
    "legalTexts": [
      {
        "code": "BE:GKS_DOCUMENT_HEADING",
        "text": "BTW-KASTICKET",
        "languageCode": "nl-BE",
        "displayRole": "DOCUMENT_HEADING"
      },
      {
        "code": "BE:FDM_FOOTER_01",
        "text": "<exact first footer line>",
        "displayRole": "FOOTER"
      },
      {
        "code": "BE:FDM_FOOTER_02",
        "text": "<exact second footer line>",
        "displayRole": "FOOTER"
      }
    ],
    "additionalFields": [
      {
        "code": "BE:TERMINAL_ID",
        "value": "<exact terminalId>"
      },
      {
        "code": "BE:INPUT_DEVICE_ID",
        "value": "<exact deviceId>"
      },
      {
        "code": "BE:EVENT_LABEL",
        "value": "<exact fdmRef.eventLabel>"
      },
      {
        "code": "BE:TOTAL_COUNTER",
        "value": "<exact fdmRef.totalCounter>"
      }
    ]
  }
}
```

The placeholders show placement only. Supply the values returned by the
merchant's certified POS and FDM integration.

## Generated CHEQI and UBL output

The local engine preserves the heading in the generated CHEQI JSON:

```json
{
  "jurisdictionalData": {
    "countryCode": "BE",
    "regime": "BE_GKS",
    "regimeVersion": "2026-07",
    "legalTexts": [
      {
        "code": "BE:GKS_DOCUMENT_HEADING",
        "text": "BTW-KASTICKET",
        "languageCode": "nl-BE",
        "displayRole": "DOCUMENT_HEADING"
      }
    ]
  }
}
```

UBL Invoice and UBL PurchaseReceipt carry the same exact value in Cheqi's
structured UBL extension:

```xml
<ext:UBLExtensions>
  <ext:UBLExtension>
    <ext:ExtensionAgencyID>CHEQI</ext:ExtensionAgencyID>
    <ext:ExtensionVersionID>1</ext:ExtensionVersionID>
    <ext:ExtensionURI>urn:cheqi:ubl:extension:jurisdictional-legal-text:1</ext:ExtensionURI>
    <ext:ExtensionContent>
      <cheqi:JurisdictionalLegalTexts>
        <cheqi:LegalText
            code="BE:GKS_DOCUMENT_HEADING"
            displayRole="DOCUMENT_HEADING"
            languageCode="nl-BE">BTW-KASTICKET</cheqi:LegalText>
      </cheqi:JurisdictionalLegalTexts>
    </ext:ExtensionContent>
  </ext:UBLExtension>
</ext:UBLExtensions>
```

The document root declares:

```xml
xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2"
xmlns:cheqi="urn:cheqi:ubl:extension:components:1"
```

This heading is not written to `cbc:Note`. That element stays available for the
free receipt message configured by the merchant in the Cheqi app, such as a
thank-you or return message. It is not part of the receipt payload.

## Merchant ID and terminal ID on card receipts

Card-payment slips often also show a merchant ID and terminal ID. Those are
payment-acquirer identifiers, not Belgian GKS identifiers:

- the acquirer merchant ID identifies the merchant account at the card
processor
- the acquirer terminal ID identifies the payment terminal or acquiring
endpoint


Supply them during recipient resolution so the backend can include them in the
server-known `paymentMeans` context:

```json
{
  "paymentType": "CARD_PAYMENT",
  "cardDetails": {
    "paymentAccountReference": "<card PAR used for matching>",
    "cardProvider": "<card scheme>",
    "lastFourDigits": "<last four digits>"
  },
  "merchantId": "<exact MID from the payment integration>",
  "paymentTerminalId": "<exact TID from the payment integration>"
}
```

They appear in the generated CHEQI receipt as `paymentMeans.merchantId` and
`paymentMeans.paymentTerminalId`. In UBL PurchaseReceipt they map to
`cac:Payment/cbc:MerchantID` and
`cac:Payment/cbc:PaymentTerminalID`.

Do not put a card-payment terminal ID in `BE:TERMINAL_ID`. The latter is the GKS
fiscal POS `terminalId`. Likewise, `cashRegisterId` identifies the fiscal POS
and `fiscalDeviceId` identifies the FDM.

For an ordinary receipt, omit `jurisdictionalData`. Do not attach GKS evidence
unless the merchant system actually produced it.

## Related

- [Supplying jurisdiction data](/countries/jurisdictional-data)
- [Recipient resolution](/receipts/recipient-resolution)
- [Country support boundary](/countries/overview)