Skip to main content

Fiscal Requirements

The EFR implementation for SCE 2.0 is based on the Ministerial Decree of 29 April 2024, which defines the technical and functional requirements for certified cash register systems and their interaction with the Fiscal Data Module. The EFR supports these requirements by ensuring compliant event registration, submission of events to the Fiscal Data Module for digital signing, data retention, and legally required exports as specified for the Belgian SCE 2.0 framework.

POS Certification in Belgium (SCE 2.0)

Purpose

The SCE 2.0 certification ensures that a POS system complies with Belgian fiscal regulations by guaranteeing:

  • integrity of fiscal data
  • full traceability of transactions

A certified system (SCE) consists of:

  • a POS system
  • a Fiscal Data Module (FDM)

info

The POS must generate and transmit fiscal data correctly to the FDM. The FDM signs and forwards this data to FPS Finance.

Process Overview

The certification process is managed by FPS Finance and consists of:

  • Pre-intake
  • Intake meeting
  • Testing and certification

A separate process applies for:

  • post-certification updates
  • system registration and deployment

Pre-intake

Objective

Ensure the POS system is ready for certification.

Scope

Eligibility check

The POS must:

  • process fiscal transactions
  • go beyond order-taking functionality
  • support transaction corrections

Feature definition

All POS features must be:

  • documented
  • version-specific where applicable

warning

Undocumented features are not allowed.

Product configuration

The POS must include predefined product lines for testing:

  • VAT 21%
  • VAT 12%
  • VAT 6%
  • VAT 0%
  • VAT exempt

Test environment

A fully functional POS test setup is required:

  • including all hardware components
  • including all supported peripherals

Documentation

Required documentation:

  • certification application (signed)
  • list of importers/distributors
  • user manual
  • installation manual
  • technical/design documentation
  • database and log access description
  • certification test report (PDF)

note
Intake meeting

Objective

Validate readiness for certification.

Activities

  • installation and presentation of the POS
  • validation of documentation
  • verification of test machine
  • registration of hardware components

Configuration requirements:
  • predefined user roles (Manager, Waiter, Trainee)
  • FDM integration (real or simulated, documented)

Timeline

Up to 3 months from intake approval.

Testing and certification

Objective

Verify compliance with SCE requirements.

Activities

  • execution of test scenarios
  • validation of fiscal data handling
  • verification of POS–FDM communication

Outcome

Success
  • POS is certified as SCE
  • system can be deployed

Failure
  • corrections required or process terminated
Post-certification registration

Objective

Register the certified SCE system for use by end customers and enable fiscal operation.

Registration links: https://www.systemedecaisseenregistreuse.be/fr/enregistrement

Scope

After certification, each installation of an SCE must be registered with FPS Finance.

Registration requirements

For each installation, the following elements must be registered:

  • certified POS system
  • FDM (Fiscal Data Module)
  • business (end user)
  • installation details (location, identifiers)

info

FPS Finance maintains a central registry of all SCE installations.

Responsibilities

POS provider / distributor
  • install the certified POS and FDM
  • ensure correct configuration
  • provide required installation details

End user (merchant)
  • ensure the system is properly registered
  • use the SCE in compliance with fiscal rules

Key considerations

  • only certified systems can be registered and used
  • POS and FDM must be linked correctly
  • incorrect or missing registration may lead to non-compliance
Post-certification updates

Objective

Certify changes without full re-certification.

Scope

Applies to:

  • bug fixes
  • new features
  • minor changes

Requirements

  • changelog
  • signed declaration
  • updated SHA1 signatures

Timeline

Typically completed within 15 working days.

Compliance requirements

  • fiscal data must be immutable
  • all features must be documented
  • the test environment must be reproducible
  • POS–FDM communication must be compliant
  • systems must be registered before use

warning

Non-compliance may delay certification or prevent deployment.

VAT Rates

Following rates are used by default, if only TaxG is delivered, but no tax rate in TaxA element:

TaxGDescriptionPrc
AStandard21
BMid12
CLow6
DZero0
XOutside VAT Scope0

Allowed values for Pos.QtyU

QtyU must match one of the following (case-insensitive):

QtyU valueDescription
pc, piecePiece (default)
kg, kilogramKilogram
m, meterMeter
l, litreLitre
h, hourHour

Ticket Medium

To specify the output medium, use ESR.DO.

Allowed values (case-insensitive):

  • "NONE"
  • "PAPER"
  • "DIGITAL"

You may specify one or more values. To combine multiple values, separate them with a pipe (|):

  • "PAPER|DIGITAL" (output on both paper and digital medium)

Rounding Rules

The new articles VI.7/1 and VI.7/2 of the Code of Economic Law require the merchant to round the total payment amount in cash by the consumer to the nearest multiple of 5 cents.

  • 1,2,6,7 are rounded down to the nearest multiple of 5 cents
  • 3,4,8,9 are rounded up to the nearest multiple of 5 cents
  • Payments of less than 5 cents are never rounded
  • Rounding is mandatory for cash payments
  • If the merchant wants to round all payments, regardless of the payment method, the cash register must provide this option
  • Vouchers always have a fixed value and are never rounded. When paying with vouchers they must always be processed first

Operator Login and Logout

Operator login and logout are handled using the business cases NFS="LOGIN" and NFS="LOGOUT". Transactions which need to be signed by the FDM are only accepted if the referenced operator is currently logged in. After a successful login, the operator remains logged in until a corresponding logout transaction for that operator is sent. For more information, see Cashier Login and Cashier Logout.

X & Z Reports

When issuing X or Z-Reports, the EFR will respond with both the necessary "turnover" and "users" report data in the same request. Besides the creation of a file for each report, which is done by the EFR, a cash register must also make it possible for the operator to easily create a printout of the report.

Z-Reports are generated automatically if they have not been created manually within 24 hours after the opening of the business day, in accordance with the applicable regulatory requirements. This ensures that the mandatory daily reports are always produced, even if the operator does not explicitly trigger them.

Report Files

Issuing of X and Z Reports will also export these reports as individual files in the directory rn/.../report.

Printout Content Requirements

Turnover Report

The "turnover" report, in addition to bearing the title ‘X OMZET’ or ‘Z OMZET’ in uppercase at the top, must contain at least the following information for the relevant opening period:

  • The name or legal name of the taxable business
  • The VAT identification number of the business referred to in (a), as per Article 50 of the VAT Code
  • The establishment number (KBO) of the operation where the GKS is installed and to which this report relates
  • The date and time of report generation
  • Identification of the cash register(s) to which the report applies
  • The FDM’s production number and the references of the first and last events recorded in the FDMs included in the report
  • The booking date to which the report relates
  • The date and time of the start and end of the opening period
  • The total turnover amount for event label N (including VAT)
    • also broken down by main groups/departments (if used)
  • The taxable base amounts, per applicable VAT rate, for event label N
  • The VAT amounts, per applicable VAT rate, for event label N
  • The total amount of:
    • turnover for event label N (including VAT), broken down per applicable VAT rate (sum of amounts in k. and l.)
    • registered payments, categorized by payment method used and recorded
    • rounding adjustments, as recorded in the payment lines
  • The number of VAT receipts issued (event label N)
  • The number of cash drawer openings without a registered transaction
    • training tickets generated (event label T)
    • return tickets generated
    • pro forma tickets generated (event label P)
    • granted discounts and surcharges, broken down by type
  • Overview of amounts (incl. VAT) from functionalities such as corrections, returns, line cancellations, etc., other than those in point u, that reduced the total turnover, regardless of the original event label (P or N), broken down by type
  • The numbers and amounts (incl. VAT) of the invoices created in accordance with Article 31
  • Reference of the first and last event included in the report
  • Z-Reports only:
    • a sequential number from an unbroken series

Operator Report

The "users" report, in addition to bearing the title ‘X GEBRUIKERS’ or ‘Z GEBRUIKERS’ in uppercase at the top, must contain at least the following information:

  • The name or legal name of the taxable business
  • The VAT identification number of the business referred to in (a), as per Article 50 of the VAT Code
  • The establishment number (KBO) of the operation where the GKS is installed and to which this report relates
  • The date and time of report generation
  • Identification of the cash register(s) to which the report applies
  • Reference to the first and last event included in the report
  • Per user:
    • username and INSZ number
    • total turnover amount generated (incl. VAT), calculated as described in point i. of the turnover report
    • status of the cash drawer contents at the end of the period (if this function is used), broken down by recorded and used payment methods
    • login and logout times on the cash register system, as recorded via the Social event and transmitted to the FDM, provided the operator chooses to use this feature
    • time of the first and last created event
  • Z-Reports only:
    • a sequential number from an unbroken series

Example Response
<TraC SQ="517">
<Result RC="OK"/>
<ESR D="2026-01-29T08:29:01" FN="R:001/POS-1-BAR/FDM02088434-20260129072902-651-3804-235"/>
<Fis ZI="9">
<Tag Label="" Value="FDM02088434" Name="ID"/>
<Tag Label="" Value="2026-01-29T08:29:02+01:00" Name="TS"/>
<Tag Label="" Value="R 651-3804-235" Name="FN"/>
<Tag Label="" Value="CPOS0031234567 9.9.9" Name="POSInfo"/>
<Tag Label="" Value="F0:1D:3D:CC:13:C8" Name="Dev"/>
<Tag Label="" Value="2000000042" Name="LocLegalId"/>
<Tag Label="" Value="001/POS-1-BAR" Name="TLT"/>
<Tag Label="" Value="THIS IS NOT A VALID VAT RECEIPT" Name=""/>
<Z ZI="9" T="102.04" DrawerOpenCnt="0" CreditAmt="-52.00" CreditCnt="1" DiscountCnt="0" DiscountAmt="0.00" SurchargeCnt="0" SurchargeAmt="0.00" ZPeriod="2026-01-29" TSDayOpen="2026-01-29T08:28:56+01:00" TSDayClose="2026-01-29T08:29:01+01:00">
<ZFisUnitA>
<ZFisUnit ID="FDM02088434" TSFirst="2026-01-29T08:28:57+01:00" FirstNum="3793" TSLast="2026-01-29T08:29:01+01:00" LastNum="3802"/>
</ZFisUnitA>
<ZFisTraA>
<ZFisTra Dsc="P" Cnt="4" Amt="250.00"/>
<ZFisTra Dsc="N" Cnt="4" Amt="102.04"/>
<ZFisTra Dsc="R" Cnt="2" Amt="0.00"/>
</ZFisTraA>
<ZCatA>
<ZCat Cat="10" CatN="Aperitifs" Net="19.83" TAmt="4.17" Amt="24.00"/>
<ZCat Cat="22" CatN="Main Dishes" Net="35.71" TAmt="4.29" Amt="40.00"/>
<ZCat Cat="12" CatN="Soft Drinks" Net="2.51" TAmt="0.53" Amt="3.04"/>
<ZCat Cat="15" CatN="Wines" Net="28.93" TAmt="6.07" Amt="35.00"/>
</ZCatA>
<ZPayA>
<ZPay Dsc="CONTANT" Amt="99.00"/>
<ZPay Dsc="Master Card" Amt="3.04"/>
<ZPay Dsc="rounding" Amt="0.00"/>
</ZPayA>
<ZCreditRsnA/>
<ZTaxA>
<ZTax TaxG="A" Prc="21" Net="51.27" TAmt="10.77" Amt="62.04"/>
<ZTax TaxG="B" Prc="12" Net="35.71" TAmt="4.29" Amt="40.00"/>
</ZTaxA>
<ZOprA>
<ZOpr OprSSN="75061189702" Amt="0.00" TSFirst="2026-01-29T08:28:56+01:00" TSLast="2026-01-29T08:29:00+01:00">
<ZAuditA>
<ZAudit Code="CLOCKIN" TS="2026-01-29T08:28:56+01:00"/>
</ZAuditA>
</ZOpr>
<ZOpr OprSSN="84022899837" Amt="102.04" TSFirst="2026-01-29T08:28:57+01:00" TSLast="2026-01-29T08:28:59+01:00">
<ZAuditA/>
</ZOpr>
</ZOprA>
</Z>
</Fis>
</TraC>

Direct and Supplementary Invoices

In accordance with the Belgian SCE 2.0 legal framework, it is prohibited to create direct invoices at a cash register in Belgium. The EFR will only accept direct invoices in the form of E-Invoices, while Supplementary invoices are always permitted at cash registers.

To read more about direct and supplementary invoices, see our Business Cases.

Device ID

By default, Trm.Serial is used as the device identifier. When a transaction is entered on a device other than the cash register itself, ESR.Dev must be provided to identify the originating device. The value should contain a hardware identifier, preferably the device serial number; if not available, a MAC address or IP address may be used. For online orders entering the POS, an IP address or platform URL may be provided.

Export/Audit Events

See also: Business Cases: Export/Audit Events

CLOCKIN

The registration of the start of an employee's presence at the workplace.

<Audit Code="CLOCKIN" Dsc="Employee clock in" TL="001" TT="1" OprSSN="00000000097" OprN="Operator name" />
CLOCKOUT

The registration of the end of an employee's presence at the workplace.

<Audit Code="CLOCKOUT" Dsc="Employee clock out" TL="001" TT="1" OprSSN="00000000097" OprN="Operator name" />
DRAWER_OPEN

Drawer opening outside of a sale.

<Audit Code="DRAWER_OPEN" Dsc="Drawer open" TL="001" TT="1" OprSSN="00000000097" OprN="Operator name" />