ERP and accounting software for Belgium - Peppol B2B e-invoicing, VAT and three official languages

Belgium is live, and that changes the conversation

Structured B2B e-invoicing became mandatory in Belgium in January 2026, exchanged over the Peppol network using Peppol BIS, with businesses required to both send and receive. Everything else on this page follows from that single fact, and it is worth stating first because it makes Belgium different from three of its neighbours.

A live mandate changes what a software evaluation is for. In a market without one, you are comparing efficiency. In Belgium, you are first establishing whether a system can participate in the network at all, and only then comparing everything else. A product that cannot send and receive structured invoices is not a cheaper option; it is a different category of thing.

It also changes the failure mode. Where invoices travel as data between systems, a malformed document does not get quietly accepted by a human who reads past the error. It is rejected, and it is rejected by a machine that will not make allowances. Businesses moving from PDF invoicing usually discover the true state of their customer master data in the first month.

Confirm your own scope and obligations with FPS Finance, the Federal Public Service Finance, rather than relying on a summary. Mandates have carve-outs and the detail of who is in scope is a question about your business.

• Mandatory for B2B since January 2026.
• Exchange over the Peppol network using Peppol BIS.
• Both sending and receiving capability are required.
• Malformed documents are rejected by machines, not tolerated by people.
• Confirm scope with FPS Finance.

How a network model actually works

It helps to be concrete about what Peppol is, because the mental model people bring from portal-based systems is wrong. Peppol is a network with a four-corner shape. You connect to an access point. Your customer connects to theirs. Each participant has an identifier that lets the network find them. The document moves supplier to access point to access point to customer.

The tax authority is not standing in the middle of each document, which is the essential difference from a clearance country. In Poland, an invoice goes through KSeF to the authority and is approved before it reaches the buyer, and the authority assigns the invoice identifier. In Belgium, the document goes to your customer over shared infrastructure. Both are structured, mandatory and machine-validated; only one puts the state in the transaction path.

The practical consequences of the network model are that your customer must be reachable, that your own identifier must be registered correctly, and that a delivery can fail for reasons outside your accounting department. Somebody has to own the failure queue. That role is usually invented after the first month of live operation, which is later than it should be.

Skyline Nexus keeps the outbound document, its delivery status and the customer identifier together with the invoice record, so that a rejected document is visible next to the transaction it belongs to rather than in a separate technical log nobody reads.

• Four corners: sender, sender access point, receiver access point, receiver.
• Participants are found by registered identifiers on the network.
• The tax authority does not sit in the middle of each document.
• Delivery can fail; someone must own the failure queue.
• Keep delivery status attached to the invoice record, not in a separate log.

Receiving is the half that gets underestimated

Sending gets all the attention because it is the visible half and the one finance controls. Receiving is where unprepared businesses actually get hurt. The obligation covers both, and the moment your suppliers are also in scope, structured invoices start arriving whether or not anyone has decided where they go.

An inbound structured invoice is an opportunity and a hazard at the same time. The opportunity is that supplier invoice data arrives as fields rather than as a PDF someone retypes, which removes an entire category of keying error from accounts payable. The hazard is that a document with no home becomes an unrecorded liability, and unrecorded liabilities are found at year end by auditors rather than in month two by controllers.

The design question is what happens to an inbound invoice that does not match anything. No purchase order. A supplier not on file. Quantities that differ from what was received. In a paper process a human absorbs the mismatch. In a structured process the system has to have an answer, and the answer has to be a queue with an owner rather than a silent rejection.

There is a payoff on the other side of that work. Once inbound invoices arrive as fields and are matched against orders and goods received automatically, accounts payable stops being a data entry function and becomes an exception handling function. Businesses that plan for that shift redeploy people; businesses that do not end up with the same headcount doing the same keying from a different screen, and conclude that structured invoicing delivered nothing.

• Inbound capability is required, not optional.
• Structured supplier invoices remove keying errors from accounts payable.
• An inbound invoice with no home becomes an unrecorded liability.
• Decide what happens on no purchase order, unknown supplier, quantity mismatch.
• Exceptions need a named owner and a visible queue.
• Match against goods received, not only against the order.

Three languages is an operational fact, not a preference

Belgium has three official languages: Dutch, French and German. For a business operating across the country, that is not a question about which language the software menus are in. It is a question about which language a customer receives their invoice in, which language a purchase order goes out in, and whether a system can hold both an item description and its translation without one overwriting the other.

The usual failure is a system that supports one interface language per user and calls that multilingual. Document language and interface language are different settings, and the one that matters commercially is the document. A Flemish customer and a Walloon customer should be able to receive the same catalogue item described in their own language from the same product record.

Structured invoicing does not remove the language question, because a human-readable rendering still accompanies the process and correspondence around a disputed invoice is still written by people. If anything, it raises the stakes, because the description that reaches a customer is now generated from data rather than typed by someone who knew the customer.

Skyline Nexus was built bidirectionally for Arabic and English, which means its document layer was designed for multiple languages from the beginning rather than translated after the fact. That is the property a Belgian business needs; the specific language pair is a configuration.

• Dutch, French and German are all official languages.
• Document language and interface language are separate concerns.
• Item descriptions need translations held against the same product record.
• Language selection should follow the customer, not the user issuing the document.
• Correspondence and dispute handling are part of the language requirement.

Where Belgium sits among its neighbours

Belgium is the network case in a set of four European markets that have chosen four different answers. Poland is the clearance case: the invoice goes through KSeF to the tax authority for approval before it reaches the buyer, and KSeF assigns the invoice its identifier. Belgium exchanges structured invoices over Peppol between trading partners, with the authority not in the document path.

Spain is a third shape. Its rules on billing software, VeriFactu, are phasing in, while the Crea y Crece B2B e-invoicing mandate is approved but not yet in force. The Netherlands is the fourth: no domestic B2B mandate at all, public sector invoicing over Peppol, and a design framework aimed at 2030.

The distinction worth carrying away is clearance versus post-audit. Clearance means the state validates the document in real time and errors surface immediately. Post-audit means nothing fails at issue and problems accumulate until an inspection. Belgium sits closer to post-audit in that respect, with the network providing machine validation of format even though the authority is not approving each invoice.

A group operating across these four countries needs country behaviour attached to the entity, not a single European switch. Assume divergence; it is the stable assumption.

• Poland: clearance, authority approves before the buyer sees the invoice.
• Belgium: network exchange over Peppol, live since January 2026.
• Spain: billing-software rules phasing in, B2B mandate approved and pending.
• Netherlands: no domestic mandate in force, framework targeting 2030.
• Clearance surfaces errors immediately; post-audit defers them to inspection.

Belgian VAT when the invoice is data

Belgium applies a standard VAT rate of 21 percent, in euro. The arithmetic is not the difficulty. The difficulty is that once invoices travel as structured data, the VAT treatment on each line is exposed as a field rather than absorbed into a total, and configuration errors that used to pass unnoticed become visible to the receiving system.

Intra-EU trade is where this concentrates. Supplies to VAT-registered businesses in other member states, reverse charge on many business-to-business services, and the customer VAT identification number all have to be present and correct as data. A number typed into a free-text field is not data. A number held as a validated field on the customer record, with the validation stored, is.

Rounding deserves a decision rather than a default. VAT computed per line and VAT computed on the document total produce different answers, and in a structured exchange the difference is not something a human reconciles quietly. Choose the basis, apply it in every channel, and be able to show which was used.

The same reasoning applies to tax classification on the item. Where a rate is chosen by a person at the moment of sale, a mixed catalogue produces a distribution of answers and no way to identify the wrong ones without reading every invoice. Where the treatment is a property of the product record, the same item is taxed identically in every channel and a mistake is corrected once at source rather than transaction by transaction.

• Standard VAT rate 21 percent, in euro.
• VAT treatment must be correct as data per line, not only in the total.
• Hold customer VAT identification numbers as validated fields.
• Reverse charge is a stored treatment with required document wording.
• Decide the rounding basis once and apply it everywhere.
• Every return figure should trace to the invoices behind it.

Master data is the project, whatever the vendor says

Most Belgian e-invoicing implementations that go badly do not go badly because of the connector. They go badly because the customer master was never accurate enough to be read by a machine. Legal names that differ from trading names. VAT identification numbers with typos that a human eye corrected silently for years. Two records for the same customer. No network identifier at all.

Under a network model, each of those becomes a delivery failure or a rejection. The invoice does not arrive, the customer does not pay, and the problem is discovered when someone chases a receivable that was never received. The remedy is unglamorous and has to happen before go-live: deduplicate, validate, and record the participant identifier against the customer.

The same discipline applies on the purchase side. Suppliers need identifiers too, and the accounts payable process needs to know which suppliers will be sending structured documents and which will still be sending PDFs during any transition. Running two inbound paths is normal; running two inbound paths without knowing which supplier is on which is not.

This is also the part of the work that survives every future rule change. Format decisions expire. Clean master data does not.

• Deduplicate customers before go-live, not after.
• Validate VAT identification numbers rather than trusting keyed values.
• Record network participant identifiers against customers and suppliers.
• Reconcile legal name against trading name on every account.
• Know which suppliers send structured documents and which still send PDFs.

Reporting frameworks in a Belgian group

Listed companies in the European Union report their consolidated accounts under IFRS as adopted by the EU, while individual entities commonly prepare statutory accounts under local generally accepted accounting principles. A Belgian entity inside an international group therefore typically serves two presentations from one transaction record.

That is a structural difference from much of the Gulf, and it is worth being explicit about because it decides how much detail has to be retained at posting time. The differences between presentations usually appear in recognition timing, in leases and provisions, and in disclosure, rather than in the invoice document itself. But if the underlying record is thin, neither presentation can be produced without manual work.

What a system contributes is detail and traceability: entity, branch, cost centre and project as dimensions on the posting; subledgers reconciled to control accounts; intercompany transactions identifiable for elimination. Which framework applies, and how a specific item is treated under it, is a determination for your auditor rather than a software setting.

For a Gulf-headquartered group with a Belgian operation this is often the largest structural difference encountered, larger than the e-invoicing mandate itself, because it changes what the local finance team is producing rather than only how a document is transmitted. It is also the part most often discovered late, since the invoicing project has a deadline attached and the reporting question does not.

• EU listed companies: IFRS as adopted by the EU for consolidated accounts.
• Individual entities: commonly local GAAP for statutory accounts.
• Keep entity, branch and project as posting dimensions.
• Make intercompany transactions identifiable for elimination.
• Framework determinations belong to your auditor.

Questions worth asking a supplier about Belgium

With a live mandate, the useful questions are specific and answerable in a demonstration rather than in a brochure. Start with the two halves of the obligation and do not accept a single answer that covers only one.

Can the system send a structured invoice over Peppol, and can it receive one? Where does an inbound invoice land, and what happens when it matches nothing? What does a delivery failure look like to a finance user, and who is expected to act on it? Can the same product record carry Dutch, French and German descriptions? Is the customer participant identifier stored against the customer?

Then ask about the neighbours, because that is where a group discovers whether it has one system or four. What does the same product do in Poland, where the authority clears the invoice? In Spain, where the billing-record rules apply? In the Netherlands, where nothing is mandated yet?

• Demonstrate sending and receiving, not just sending.
• Show where an unmatched inbound invoice goes and who owns it.
• Show a delivery failure as a finance user would see it.
• Show one product record carrying three language descriptions.
• Show the participant identifier stored on the customer record.
• Ask what changes in Poland, Spain and the Netherlands.

Confirm the position with FPS Finance

This page reflects the position as confirmed on 7 September 2026: structured B2B e-invoicing mandatory in Belgium since January 2026, over the Peppol network using Peppol BIS, with businesses required to both send and receive.

Scope, exceptions and the treatment of particular cases are questions about your business rather than facts about the country, and they are properly answered by FPS Finance, the Federal Public Service Finance, or by a Belgian adviser. Rules in this area are also amended, and a page is not a source of law.

What a software supplier can honestly describe is capability: what the system records, what it produces, what it can send and receive, and what it prevents. No product is a guarantee of compliance and none should be presented as one.

• Authority: FPS Finance (Federal Public Service Finance).
• Position stated as confirmed on 7 September 2026.
• Confirm your own scope and any exceptions before relying on a summary.
• No software certifies you as compliant with the Belgian mandate.

Common questions

Is e-invoicing mandatory in Belgium?

Yes. Structured business-to-business e-invoicing became mandatory in January 2026, exchanged over the Peppol network using Peppol BIS. Businesses must be able to both send and receive structured invoices. Confirm your own scope and any exceptions with FPS Finance.

What is Peppol and how does it work?

Peppol is a network with a four-corner shape: you connect to an access point, your customer connects to theirs, and the invoice moves between them over shared infrastructure using registered participant identifiers. Unlike a clearance system, the tax authority does not sit in the middle of each document.

Do we have to be able to receive e-invoices as well as send them?

Yes, both. Receiving is the half most businesses underestimate, because it is invisible until a supplier sends a structured invoice and there is nowhere for it to land. Decide in advance what happens to an inbound invoice with no purchase order, an unknown supplier or a quantity mismatch, and give that exception queue a named owner.

How does Belgium differ from Poland?

Poland operates a clearance model: the invoice goes through KSeF to the tax authority, is approved before it reaches the buyer, and KSeF assigns the invoice identifier. Belgium operates a network model: structured invoices move over Peppol directly between trading partners, with the authority outside the document path. Both are mandatory and structured; only Poland puts the state in the transaction path.

Which language should Belgian invoices be issued in?

Belgium has three official languages, Dutch, French and German, so document language is a real operational question rather than a software preference. A system should hold item descriptions in more than one language against the same product record and select the document language from the customer, not from the user issuing it.

Rates, regimes and deadlines in this summary change, and many countries are actively legislating on e-invoicing. This is general information, not tax or legal advice — confirm the current position with the authority named above or with your tax adviser before you rely on it.