North Macedonia E-Invoicing Requirements: e-Faktura 2027 Timeline

North Macedonia e-invoicing requirements are being set by a draft Law on Electronic Invoicing, which the Ministry of Finance published for public consultation in August 2026. It proposes voluntary use of the e-Faktura system from October 1, 2026 and mandatory issuance and receipt from April 1, 2027 for VAT-registered businesses, with further groups following in phases until January 1, 2028. Those dates become binding only once the Assembly adopts the law and it is published in the Official Gazette. The system itself has been in Public Revenue Office (UJP) testing since January 1, 2026, and the Ministry announced it on January 5, 2026.

• Status now: The law is still a draft, so no business is yet obliged to use e-Faktura. UJP is in its third test phase, with a free web application any company can use to practice creating, sending, accepting, rejecting and cancelling e-invoices.
• Scope split: e-Faktura is meant to carry invoiced transactions, domestic and foreign, while transactions for which a fiscal receipt has been issued stay under fiscalization rules.
• Planning takeaway: VAT-registered businesses should plan to be ready by April 1, 2027, the first proposed mandatory phase, and every finance team should map which invoices will need registration and which documents stay in the fiscal-receipt lane, because the two workflows are not interchangeable.

That split matters more than the file format alone. North Macedonia e-Faktura requirements are moving some invoices away from the older PDF-friendly baseline and toward centralized validation, while AP teams, accountants, controllers, and SMB finance operators still need to control intake, storage, and reconciliation across both lanes.

What Changed From North Macedonia's 2020 PDF Invoice Rules

Before e-Faktura, the practical baseline in North Macedonia was much lighter. A 2020 Ministry decree allowed businesses to issue invoices electronically in PDF format even without a digital-signature certificate, so for many finance teams the working assumption became straightforward: create the invoice, send the PDF, and keep the document trail.

That is the assumption this North Macedonia electronic invoicing guide needs to reset. Under the e-Faktura model for in-scope invoices, compliance is no longer defined just by whether a PDF was generated and delivered. The key change is centralized validation. The authoritative invoice record is expected to be the structured data accepted through the platform, not simply the visual invoice file sitting in email, ERP output, or shared storage.

This means the legal and process shift is bigger than a file-format change. In the PDF-first regime, the document itself did most of the compliance work. In the e-Faktura regime, finance teams need to focus on when an invoice is considered valid, which system event proves submission or acceptance, and what audit evidence shows the invoice passed through the required controls. For affected transactions, sending a PDF alone is no longer the whole story.

Digital signatures move in the opposite direction. In 2020, the headline point was that a PDF invoice could be issued electronically without a certificate-backed signature. The draft law reverses that for in-scope invoices: each e-invoice is issued through the e-Faktura system and signed with a qualified electronic signature, and UJP's test instructions already require companies to register a valid digital certificate and submit digitally signed test invoices. The signature now sits on the structured invoice data rather than on a PDF, and it is checked together with the platform's validation rules.

That does not mean PDFs disappear from business operations. Companies may still generate PDF views, attach supporting documents, exchange backup files with customers or auditors, and store human-readable copies for internal workflows. But for in-scope e-Faktura transactions, those files are supporting artifacts. The compliance anchor shifts to the structured invoice data and the platform-validated record behind it.

Which Transactions Go Through e-Faktura and Which Stay in Fiscalization

The clearest way to read the rules is as a two-lane system. Under the draft law, the obligation falls on businesses and public bodies, and the main exclusions are transactions for which a fiscal receipt has been issued and banking and financial services that are exempt from VAT. UJP has said the system will cover all transactions in both domestic and foreign trade, so imports and exports sit inside the scope rather than outside it. Cash versus non-cash is a useful shorthand for North Macedonia non-cash invoice rules, but the legal line is the fiscal receipt. In practice, that points finance teams toward B2B and B2G invoice flows as the main volume they need to map into e-Faktura.

Sales recorded with a fiscal receipt sit in a different lane. They remain tied to North Macedonia's existing fiscalization framework, not the centralized e-Faktura clearance process. If you need a refresher on North Macedonia cash-register and fiscal receipt rules, treat those obligations as separate from invoice clearance. That distinction matters because North Macedonia fiscalization vs e-Faktura is not just a technical difference, it is a compliance boundary.

A quick way to classify common flows is:

• Invoiced B2B or B2G supply with no fiscal receipt issued: e-Faktura lane
• Retail sale recorded through a cash register with a fiscal receipt: fiscalization lane
• Import, export or foreign-supplier invoice: inside the scope UJP describes, since the system is to cover foreign trade. How a foreign supplier's invoice reaches the platform is one of the details to confirm in the final specifications, and where the VAT falls on you, the North Macedonia reverse-charge invoice rules and DDV-04 reporting still apply alongside it.
• Supplier sends a PDF copy of an in-scope invoice: the PDF may support the workflow, but the structured e-Faktura record is the authoritative compliance record

Edge cases still need checking against the adopted law and UJP's final guidance, but those examples reflect the split-model logic finance teams need to work from now.

For mixed businesses, this means one sales cycle may produce two different document-control processes:

• Invoices that must be issued, validated, or exchanged through e-Faktura
• Sales that still generate fiscal receipts, cash-register records, or other fiscalized outputs

That split affects day-to-day finance work. Your VAT support, audit trail, and reconciliation process cannot assume one universal document type. A centrally validated e-Faktura record gives you one kind of evidence trail, while a fiscal receipt gives you another. AP and accounting teams need controls that distinguish between the two, especially when matching sales records, supporting VAT positions, and proving that e-Faktura invoice data and fiscal-receipt data were both handled correctly.

If your business handles both invoice-based and cash-based turnover, plan for parallel controls, not one universal invoice workflow.

North Macedonia's e-Faktura Timeline: What Is Confirmed and What Is Still Expected

For the North Macedonia e-Faktura timeline, the most useful distinction is what is already official versus what the draft law proposes. Many summaries blur together pilot activity, the public launch, and the point when mandatory e-invoicing actually begins, and some still carry dates that have since moved. The same drift affects other countries, which is why a country-by-country e-invoicing deadline tracker tied to official sources is the safer reference when comparing regimes.

What has happened so far:

• January 1, 2026: testing began. UJP started the pilot with companies connecting their ERP systems to e-Faktura. Treat this as the start of testing and controlled early use, not of a mandate.
• January 5, 2026: public launch announcement. When announcing the E-Invoicing System, North Macedonia's Ministry of Finance said the informal economy accounts for approximately 30% of GDP, framing e-Faktura as part of a broader anti-shadow-economy reform rather than just a technical invoicing change, according to the North Macedonia's Ministry of Finance e-invoicing launch announcement.
• June 4, 2026: third test phase. UJP announced the third phase of e-Faktura testing: a free web application in which any company, whatever its size or systems, can test creating, sending, accepting, rejecting and cancelling invoices without an ERP integration. About 200 selected companies are testing in a structured way with assigned UJP officials. In the second phase UJP had already changed the structure of the API calls and the JSON format.
• August 2026: draft law published. The Ministry of Finance put the draft Law on Electronic Invoicing out for public consultation on the national electronic register of regulations (ENER).

The phases the draft proposes, as EY North Macedonia summarized the draft law on its publication:

Many pages, Macedonian-language ones among them, still say e-Faktura became mandatory on October 1, 2026. Under the draft, that is the start of voluntary use. The first mandatory date is April 1, 2027, for VAT-registered taxpayers, and no date is binding until the law is adopted.

The confirmed-versus-proposed split changes how you sequence work. The test phases tell you how the system works and what it expects; the draft tells you when it is meant to become compulsory. Plan go-live readiness to April 1, 2027 if you are VAT-registered, or to your own phase if not, covering invoice classification rules, ERP changes, e-Faktura submission controls, and fallback procedures for documents that still sit outside the new flow. Then watch for the law's adoption and publication in the Official Gazette, which is when the dates become fixed. That is similar to how Latvia staged its e-invoicing rollout, where planning depended on separating phased milestones instead of treating every date as the same kind of deadline.

How the e-Faktura Workflow, Formats, and Connections Are Expected to Work

UJP's test phases show a clearance-style workflow, not just a document-sharing workflow. The invoice is created in an ERP, a billing tool, or UJP's web application, then submitted to the e-Faktura environment for checks before it counts as properly issued. The platform does more than store a copy: it validates required fields and applies system rules, and under the draft law an invoice that passes validation receives a unique invoice identification number and an electronic timestamp, the proof that it went through the official channel.

That timing matters. If your process assumes an invoice is legally issued as soon as a PDF is emailed, your controls may need to change for in-scope transactions. Finance teams should instead think in stages: draft invoice, structured submission, UJP validation, confirmed issuance, then downstream posting and customer delivery. Bookkeeping, AP matching, and audit trails all depend on knowing exactly when the invoice cleared the central system, because that timestamp can matter more than the date shown on a human-readable copy.

The technical format is set out in the specifications UJP publishes on its e-Faktura wiki (efakturawiki.ujp.gov.mk): software exchanges invoices with the platform through API calls carrying a structured JSON payload, which holds the legal and accounting data fields the platform checks automatically. A readable PDF may still exist for business users, customers, or archives, but the PDF is no longer the main compliance object. The structured data is. Teams comparing neighboring models can see a similar PDF-versus-structured distinction in Slovenia's budget-user workflow and 2028 e-invoicing shift, while Serbia's 2026 SEF rollout rules show how invoice exchange can also intersect with retail fiscalization exceptions. That is the core difference between a PDF-friendly invoicing environment and a real-time registration model.

For smaller businesses, the access path is UJP's free web application, which needs no integration. For larger issuers, higher-volume sellers, or businesses that want invoice creation and status updates to remain inside their ERP, North Macedonia e-invoice API integration is the more relevant path. Since the second test phase the API covers downloading, accepting, rejecting and cancelling invoices as well as sending them, so software can submit invoice data directly, receive validation responses, and store the resulting status and identifier in internal records. Either way, registering on the platform requires a valid qualified digital certificate. That is the same broad direction many teams are watching in neighboring reforms, including Croatia's Fiscalization 2.0 e-invoice model.

The important process question is not whether a PDF can still be viewed by a human. It is whether your system can produce the signed JSON the platform expects, handle validation errors, track acceptance or rejection, and prevent accounting teams from treating a rejected or unregistered invoice as final.

For implementation planning, finance and IT should confirm the details still open as the law and the specifications settle: the final version of the JSON schema, the deadlines and consequences when a buyer accepts, rejects or does not respond to an invoice, the exact validation and rejection rules, how foreign-trade invoices are handled, and how the identifier and timestamp must be kept in your audit trail. Those details will determine whether the web application is enough or whether API integration is the safer long-term choice.

How Finance Teams Should Prepare for North Macedonia's Mixed-Document Reality

If you are using this North Macedonia electronic invoicing guide to plan operations, the safest assumption is that your invoice process will stay mixed for a while. Some transactions will move through e-Faktura, sales with a fiscal receipt will still sit inside fiscalization rules, and your team will still see PDFs, supplier attachments, historical files, and spreadsheet-based handoffs around the edges. Preparation is less about one new submission step and more about making sure each document enters the right control path.

A practical North Macedonia e-invoice mandate checklist should cover six areas:

• Issuance controls: Decide which transactions are in scope for e-Faktura, especially where a sale is invoiced rather than covered by a fiscal receipt, and prevent staff from issuing the wrong document type for the wrong channel.
• Intake rules: Separate incoming structured invoice data from supporting files such as PDFs, contracts, delivery notes, and email attachments, but keep them connected at transaction level.
• Validation checks: Confirm that the invoice status, mandatory fields, tax values (including whether the rate charged matches the standard and reduced VAT rates by country from official sources), supplier and buyer details, and acceptance or rejection outcome match what your ERP or AP workflow expects.
• Retention: Store the authoritative e-Faktura record together with the human-readable copy, related attachments, and any fiscal receipt or cash-side evidence that belongs to the same transaction.
• Exception handling: Define what happens when an invoice is rejected, when a supplier sends only a PDF, when an attachment is missing, or when a cash transaction is recorded as if it were non-cash.
• Reconciliation: Match e-Faktura records, legacy PDF invoices, attachments, fiscalization outputs, and payment records so month-end review is based on one complete transaction file.

That matters because structured e-invoicing does not eliminate document complexity. AP teams still inherit mixed inbound documents from suppliers, archived PDF invoices from earlier periods, spreadsheets used for imports or corrections, and cash-side documents produced outside the e-Faktura path. Even in a more structured environment, you still need a reliable way to normalize what arrives from different systems and formats. That is where invoice data extraction for mixed-format invoice workflows still fits operationally: not as a substitute for the authoritative structured record, but as a way to capture supporting data from PDFs, scans, and phone photos that continue to sit around the mandated flow.

For day-to-day controls, draw a hard line between authoritative fields (invoice identifiers, dates, tax amounts, status, and counterparties, all sourced from the e-Faktura record or the fiscal system of record) and supporting documents (invoice renderings, line-item schedules, PO references, email attachments, legacy PDFs). Keep both together without letting a PDF overwrite a validated structured field.

For the next 90 days, priorities should be clear:

1. Confirm your phase: whether each entity is VAT-registered, non-VAT-registered or a public body, and which transaction types and counterparties fall within e-Faktura's scope.
2. Map every invoice-related flow by transaction type, especially the split between e-Faktura, fiscalization, and legacy PDF processes.
3. Get qualified certificates in place and test now, on UJP's web application or through the API, including rejections, cancellations, and attachment handling, well before April 1, 2027.
4. Put mixed-format controls in place now so AP, accounting, and audit teams can reconcile structured records with the supporting documents they will still need.