On 1 October 2026, North Macedonia opens the voluntary phase of its national e-invoicing system. That is four weeks away. If you are wondering whether this is new: it is not. The draft law governing e-invoicing North Macedonia was published by the Ministry of Finance in March 2026 and has not changed substantively since. The law is still a draft and is awaiting parliamentary approval. The fact that several international news services presented this as fresh news in early September 2026 does not change any of that.
What does change is the timing. A draft law from March is an agenda item without urgency for most businesses. A test environment opening in four weeks is not, especially when the first hard deadline follows six months later. This article is therefore not about the legal text but about what you need to do in practice, whether you run a Macedonian subsidiary, buy from a supplier in the region, or supply software to customers active there.
Why this matters for Dutch and Belgian organisations
The direct relevance is limited but certainly not zero. Three groups are concretely affected.
The first group consists of companies with a Macedonian entity: a subsidiary, a production site, a shared service centre or a sales office. That entity falls under the national mandate as soon as its phase starts, regardless of where the parent sits. Such an entity often runs on the same ERP system as the rest of the group, so the change lands with the central IT or finance team rather than with the local bookkeeper.
The second group is companies buying from Macedonian suppliers. They face a changed invoice format and suppliers who may run into trouble during the transition. That is not a technical problem but an accounts payable problem: invoices that do not arrive lead to payment delays and to suppliers calling your procurement department.
The third group matters most to us: software vendors, integrators and Peppol Serviceproviders with customers in South East Europe. For them this is a new roadmap item that has to be maintained separately, because it does not connect to the infrastructure they already run.
E-invoicing North Macedonia: what the draft law establishes
The draft law establishes a central e-invoicing system called “e-Faktura”, operated by the Public Revenue Office, the Macedonian tax administration (Управа за јавни приходи). That platform becomes the mandatory channel for issuing, receiving, validating, storing and exchanging e-invoices and related documents such as credit notes and corrections.
The requirements for the invoices themselves are strict. E-invoices must be structured, digitally signed, and validated in real time through the tax administration’s platform. Real-time validation is where most integration projects stumble, because the outbound invoice process acquires a synchronous dependency on an external party.
Two categories fall outside the mandate: transactions for which a fiscal receipt is issued, and VAT-exempt banking and financial services. The first is relevant for retail and hospitality, where the till receipt already serves a fiscal function.
The phased timeline
Rollout is staged across just over two years:
- 1 October 2026: voluntary participation opens
- 1 April 2027: mandatory for VAT-registered businesses
- 1 July 2027: mandatory for non-VAT-registered legal entities
- 1 October 2027: mandatory for public and budgetary institutions, non-profit institutions and the National Bank
- 1 January 2028: mandatory for all remaining entities
Alongside this legal timeline runs a phased pilot programme. The first phases started in early 2026, and the third test phase opened in the summer of 2026 for testing business processes. That pilot is separate from the voluntary phase, but it does indicate that the tax administration now considers the environment usable for more than connectivity tests alone.
An open question you need to be aware of
There is a discrepancy between sources that you should weigh honestly. Local Macedonian reporting states that suppliers to government institutions must already issue e-invoices from October 2026. That is a B2G obligation. The draft law, by contrast, designates October 2026 as the start of the voluntary phase for B2B.
The most likely explanation is that these are two separate tracks: an existing or upcoming B2G obligation running alongside the new B2B programme. That pattern is not unusual; many countries mandated public sector invoicing before business invoicing.
We explicitly do not present this as established fact. If you supply Macedonian government institutions, do not assume October 2026 is optional. Have it confirmed by a local adviser or by your Macedonian entity before you base your planning on it.
This is emphatically not a Peppol implementation
Here is the core of the story for anyone who has to build something. North Macedonia has chosen a central clearance model. The tax administration operates the platform itself and validates every invoice in real time before it counts as valid. That is the opposite of how Peppol works.
In the Peppol model, two businesses exchange invoices through their own Peppol Serviceprovider, in a decentralised four-corner model in which the government is not a party. The tax administration may require reporting afterwards, but it does not sit in the path between sender and receiver. In a clearance model, the government sits squarely in that path. That difference is not academic: it determines what your integration looks like, what it costs and where it is fragile.
What clearance means in practice
With a clearance model you build one connection to one government platform. That sounds simpler than it is. You are entirely dependent on that platform’s availability: if it goes down, you cannot issue valid invoices, and there is no alternative route. You also depend on the pace at which the tax administration gets its specifications, test environment and error handling in order. With a new platform, that is a real risk.
On the other hand, the connection itself is straightforward: one endpoint, one format, one set of validation rules.
What Peppol means in practice
With Peppol you connect through a serviceprovider to a network with multiple routes. Your serviceprovider handles the connection, addressing via the Peppol directory and transport. If one access point fails, the network as a whole is unaffected. The model is designed for redundancy and for cross-border use: the same connection serves multiple countries.
That last point is decisive for integrators. A Peppol connection scales across countries. A clearance connection does not. Every clearance country is a separate project with its own specifications, certificates, validation rules and maintenance burden.
How this compares to other countries
North Macedonia is not alone. Greece, with myDATA, operates a system that behaves in a strongly clearance-like way, sending transaction data to a government platform before it becomes final. Anyone following the Greek e-invoicing developments will recognise the patterns: phased rollout, a platform refined along the way, and businesses that only move once the deadline is in sight.
On the other side are countries choosing Peppol. Belgium built its B2B mandate on Peppol, and Slovakia recently brought its e-invoicing infrastructure into operation on the same basis. For companies active in several of those countries, that means one technical route instead of three.
Our ViDA state of play by country shows how divergent the choices within the EU already are, and North Macedonia shows that things do not get simpler outside it.
The voluntary phase is the cheapest way to remove risk
There are six months between 1 October 2026 and 1 April 2027. In those six months you can test without a mistake costing you anything. After 1 April 2027, every mistake costs you invoices that do not go out.
That may seem obvious, but practice is stubbornly different. Countries that offer a voluntary period find that it is rarely used. Businesses wait until the mandate is imminent, after which everyone turns up at the same helpdesk and the same software vendor at once. Go-live then becomes messy, not because the technology fails but because there is no time left to resolve problems calmly.
Slovakia is the positive counterexample. Around 5,000 parties registered voluntarily in advance there, which meant a substantial part of the market was already running before the mandate took effect. That is not accidental but the result of active communication and a usable test environment. For North Macedonia that test environment already exists, in the form of the pilot programme whose third phase opened this summer.
The broader pattern: the Western Balkans are ahead
There is a structural movement behind this news. The Western Balkans are digitising VAT faster than a considerable share of EU member states. Two mutually reinforcing explanations account for that.
The first is the absence of legacy infrastructure. A country that never built a large-scale EDI landscape does not have to accommodate decades of existing connections and habits. It can move to a central model in one step, exactly as North Macedonia is doing.
The second is EU accession ambition. Aligning with European standards on fiscal control and transaction reporting is part of that process, and a working national system is a visible result.
For invoicing software vendors this means something concrete and unwelcome: the list of non-Peppol mandates keeps growing, and each one has to be built and maintained separately. Anyone basing their product strategy on the assumption that Europe is converging on a single model will be disappointed. The reality is a portfolio of national connections alongside a Peppol foundation, where the Peppol part scales and the national part does not.
Checklist: what you can do now
For the business owner with a Macedonian entity, site or supplier. These steps are ordered by what needs to happen first.
- Determine whether and where you are affected. Do you have a Macedonian entity issuing invoices? Do you buy from Macedonian suppliers? Do you supply Macedonian government institutions? Each of those three leads to a different priority.
- Work out which phase applies to you. VAT-registered means 1 April 2027. Non-VAT-registered legal entity means 1 July 2027. Public or non-profit institution means 1 October 2027. All remaining entities have until 1 January 2028. Put that date in your planning, not the date the law is adopted.
- Check the B2G question. If you supply Macedonian government institutions, have it confirmed locally whether an obligation already applies from October 2026. Do not assume voluntary status.
- Ask your software vendor for a concrete commitment. Not “we are monitoring developments”, but: do you support e-Faktura, from when, and is it included in my licence or is it additional work? Get the answer in writing.
- Register for the voluntary phase from 1 October 2026. This is the core of the advice. Six months of testing room is the cheapest insurance you can buy.
- Audit your invoice data. Structured invoices with real-time validation are unforgiving about missing or incorrect fields. VAT numbers, address details and item descriptions that are currently “good enough” for a PDF will be rejected.
- Arrange digital signing. The law requires digital signatures. Working out which certificates you need and how to obtain them takes lead time you do not want to discover in March 2027.
- Think about your fallback. What do you do if the tax administration’s platform is down for a day? With real-time validation that is not a theoretical question. Document how you will buffer invoices and submit them afterwards.
- Inform your Macedonian suppliers. They are often smaller and less well prepared than you are. A supplier unable to send a valid invoice from April 2027 becomes your problem.
What this means for your integration
For the integrator, software vendor or Peppol Serviceprovider. The starting point is that you cannot reuse a Peppol solution here.
Architecture
Treat e-Faktura as a separate national channel alongside your Peppol infrastructure, not as a variant of it. The addressing model differs fundamentally: with Peppol you route to a receiver identifier via the directory, with clearance you send everything to one government endpoint. Forcing clearance traffic through your Peppol stack builds technical debt.
What you can reuse is the layer above: normalising outbound invoice data into an internal canonical model, which you then map to UBL for Peppol or to the Macedonian format. Invest there, because every subsequent national mandate pays it back.
The synchronous dependency
Real-time validation means your invoicing process waits for an external response. That has consequences beyond the connection itself:
- Design explicitly for timeouts and for platform unavailability. An invoice hanging between “sent” and “validated” needs an unambiguous status in your system.
- Build in idempotency. On a timeout you do not know whether the invoice arrived. Resending must not create a duplicate.
- Make sure rejection reasons from the platform reach the user in usable form. A technical error code in a log file is not error handling. The user needs to know which field to correct.
- Expect batch behaviour around month and quarter end. If the whole market invoices on the same day, the platform’s response time becomes yours.
Certificates and signing
Digital signing requires certificate management: issuance, storage, rotation and expiry monitoring. This is repeat work for every clearance country, and requirements differ. Build it as a generic facility, not a Macedonian exception.
Planning
Use the voluntary phase from 1 October 2026 as your integration window: connect to the test environment in October and November, run a limited set of customers in production voluntarily in December and January, and keep February and March 2027 free for scaling to your full customer base. Anyone starting in March 2027 will be queuing behind everyone who did the same.
Roadmap consequence
Record this as a structural point, not a project. The Western Balkans will produce more mandates of this kind, and your product strategy needs room for that. The question to answer internally is not “do we build e-Faktura”, but “how many national clearance connections can we structurally maintain, and where is our limit”. That is a commercial question better answered now than at the fifth country.
What could still change
The law is a draft. Parliament still has to adopt it, and until then dates can shift. That is not a reason to wait: phases in programmes like this are rarely scrapped, at most they move, and the investment you make now is needed regardless. Nor should you count on a delay. The test environment is running, the pilot is in its third phase, and the tax administration has visibly invested in the platform.
In closing
E-invoicing North Macedonia is not a Peppol story and it is not a new legislative proposal. It is a draft law from March 2026 whose first practical phase opens in four weeks, and that is what makes it relevant. For businesses connected to the country, the voluntary period between October 2026 and April 2027 is the window in which you can make mistakes without paying for them. For integrators, this is a new clearance mandate that must be built and maintained separately, with all the dependencies that entails.
Want to know which parties can help you with international e-invoicing and with combining Peppol and national mandates? Review the overview of Peppol suppliers and compare which provider fits your situation.
Sources
- KPMG North Macedonia, March 2026, Draft Law on Electronic Invoicing published in North Macedonia
- Racin.mk, local Macedonian reporting, Стартува e-Фактура: пилот од јануари
- Fiscal Solutions, country page North Macedonia, North Macedonia fiscal requirements
- Sovos, North Macedonia e-invoicing
- VATupdate, 1 September 2026, North Macedonia proposes phased e-invoicing mandate starting April 2027
