e-Invoicing Registration: How to Register? Step-by-Step Guide

As e-invoicing mandates take effect across Europe, the Middle East, and Asia Pacific, registration has become the very first compliance milestone for every business in scope. Before a single invoice can be issued or received electronically, the company must be known to the tax authority or the exchange network, and in most countries it must also formally authorize the e-invoicing service provider that will manage the process on its behalf. This guide explains what e-invoicing registration involves, who needs it, where it happens, and how the procedure works step by step in Turkey, Italy, Saudi Arabia, Poland, Malaysia, Croatia, the United Arab Emirates, and the Peppol countries of Germany, Belgium, and the Netherlands. 

What is e-Invoicing Registration? 

e-Invoicing registration is the formal process of enrolling a business in a country’s electronic invoicing system so that it can legally issue, transmit, and receive structured electronic invoices. Depending on the jurisdiction, registration can mean creating an account on a government platform, registering a routing code or electronic address, generating cryptographic credentials such as certificates and seals, or being published as a participant on an interoperable network such as Peppol. 

In practice, registration almost always has a second dimension: delegation. Most businesses do not connect to tax authority platforms directly. They authorize an e-invoicing service provider, an ERP vendor, or an accounting firm to manage invoice flows on their behalf, and the registration process is where this authorization is formally recorded. Whatever the mechanism, the legal logic is the same everywhere: the authority must be able to trust that documents submitted by a third party genuinely belong to the taxpayer, and the taxpayer remains legally responsible for every invoice issued in its name. 

Who Should Register for e-Invoicing? 

The scope of mandatory registration is defined by each country’s legislation, but the global trend is unmistakable: obligations that started with large enterprises and public sector suppliers are expanding to cover nearly all businesses. 

• Businesses in countries with live B2B mandates. In Turkey, taxpayers above the revenue thresholds or operating in designated sectors must register for e-fatura. In Italy, virtually all VAT-registered businesses participate in the SdI system. Belgium made structured e-invoicing mandatory for domestic B2B transactions from 1 January 2026, and Poland’s KSeF obligation phases in from February 2026. 
• Businesses in countries with phased rollouts. Malaysia is extending MyInvois obligations across taxpayer segments by turnover, Croatia’s Fiscalization 2.0 covers B2B invoicing from 2026, Germany is phasing in B2B e-invoicing obligations, and the UAE has set binding appointment and go-live deadlines through 2027. 
• Suppliers to the public sector. In Germany and the Netherlands, B2G e-invoicing obligations mean suppliers to public entities must be able to deliver compliant invoices through Peppol or national channels. 
• Voluntary adopters. Even where no mandate applies yet, many companies register early to test integrations, capture efficiency gains, and avoid the onboarding rush that precedes every deadline. 

A practical rule of thumb: if your customers or your tax authority can only receive invoices electronically, you need to register, regardless of your own preferences. 

Where to Register for e-Invoicing? 

The registration venue depends on the model the country has adopted: 

• Turkey: the Revenue Administration (GİB) e-fatura system, in practice through a certified private integrator. 
• Italy: the Agenzia delle Entrate reserved area, where the telematic address for receiving invoices through SdI is registered. 
• Saudi Arabia: the ZATCA Fatoora portal, accessed through the ERAD taxation portal. 
• Poland: the KSeF system of the Ministry of Finance, with permissions managed through the ZAW-FA notification and the Certificates and Permissions Module (MCU). 
• Malaysia: the MyInvois portal, accessed through MyTax on the LHDN (Inland Revenue Board) website. 
• Croatia: the ePorezna (eTax) portal of the Tax Administration, specifically the FiskApplication service. 
• United Arab Emirates: onboarding runs through an Accredited Service Provider selected from the Ministry of Finance list, linked to the taxpayer’s profile. 
• Germany, Belgium, the Netherlands: there is no government registration portal for the exchange itself; registration happens on the Peppol network through a certified Peppol service provider. 

The Universal Registration Workflow 

Although portals and terminology differ, nearly every e-invoicing registration follows the same underlying sequence: 

1. Confirm your obligation and timeline. Identify whether your entity is in scope, from which date, and for which document flows (B2B, B2G, B2C reporting). 
2. Obtain your digital identity. Most systems require a national credential first: a financial seal in Turkey, SPID or equivalent access in Italy, a qualified signature or seal in Poland, or a verified taxpayer profile in Malaysia and Saudi Arabia. 
3. Choose your connection model. Decide between the government portal (manual, low volume), direct API integration (high effort, rare), or a certified service provider (the standard choice for automated flows). 
4. Register and authorize. Complete the registration in the relevant portal or network, and formally record the authorization of your provider: a routing code, an intermediary appointment, entity permissions, a certificate, or a network participant entry. 
5. Test and validate. Most systems provide sandbox or simulation environments where the integration is verified before production. 
6. Go live and monitor. Activate production access, confirm inbound and outbound flows, and put credential expirations and representation periods on the compliance calendar. 

The sections below apply this workflow to each system, starting with centralized platforms and then moving to decentralized networks. 

How to Register for e-Invoicing in Centralized Systems? 

In centralized (clearance) models, the tax authority operates the exchange platform itself. Registration and provider authorization therefore happen directly in the authority’s own portal. 

Turkey (GİB – Revenue Administration) 

Turkey runs one of the world’s most mature clearance systems. e-Fatura documents in UBL-TR format flow through the Revenue Administration (GİB), and the vast majority of taxpayers use a certified private integrator rather than the free GİB portal or a costly direct integration. 

• Step 1: Obtain a financial seal (mali mühür). Legal entities apply to TÜBİTAK KamuSM for the financial seal, a qualified electronic certificate delivered on a smart card. This seal is the taxpayer’s cryptographic identity in the entire Turkish e-document ecosystem. 
• Step 2: Apply for the e-fatura application. The taxpayer registers for the e-fatura application, selecting the private integration method as the connection model. 
• Step 3: Sign the integrator’s authorization request. The taxpayer completes and signs an activation and authorization request in the private integrator’s system using the financial seal. The integrator transmits this request to GİB, which activates the taxpayer’s e-fatura account through the integrator’s infrastructure. 
• Step 4: Define aliases for routing. Each e-fatura user receives inbox and outbox labels (posta kutusu and gönderici birim aliases) that determine where documents are delivered. A taxpayer may hold multiple aliases and may even work with more than one private integrator at the same time, with each integrator certified by GİB per document type (e-fatura, e-arşiv, e-irsaliye, and others). 

Once the authorization is active, invoices signed and submitted through the integrator are validated by GİB and delivered directly to the buyer’s alias, with the integrator handling submission, delivery, and archiving within the legal framework. 

Italy (SdI – Sistema di Interscambio) 

Italy’s Sistema di Interscambio routes every domestic electronic invoice. Each participant is reachable through a telematic address, most commonly a seven-character Codice Destinatario assigned to an accredited transmission channel. When a business works with a service provider, it registers the provider’s Codice Destinatario in the Agenzia delle Entrate portal so that SdI automatically delivers all incoming invoices for that VAT number to the provider’s channel. 

• Step 1: Access the reserved area of the Agenzia delle Entrate portal. The legal representative or a delegated operator logs in using one of the accepted authentication methods: SPID (the Italian public digital identity), CIE (electronic identity card), CNS (national services card), or existing Fisconline/Entratel telematic credentials. SPID is only one option; any valid method works as long as the user is authorized to operate on the relevant VAT profile. 
• Step 2: Open the registration service. In the section dedicated to electronic invoicing and conservation, select the service for registering the telematic address where all electronic invoices will be received (“Registrazione dell’indirizzo telematico”). 
• Step 3: Verify the Partita IVA. Before confirming anything, check that the VAT number displayed by the portal corresponds to the correct Italian VAT profile. This matters because the registration affects the delivery of every incoming supplier invoice for that profile. 
• Step 4: Enter the Codice Destinatario. Select the Codice Destinatario option, enter the exact code communicated by the service provider, and leave the PEC (certified email) fields empty unless a PEC registration has been explicitly agreed. 
• Step 5: Confirm the registration. Review the details and submit. From that moment, SdI routes incoming invoices to the registered address regardless of what individual suppliers write on their invoices. 

One practical warning: if a different telematic address or PEC was previously registered, changing it redirects the entire inbound invoice flow, so this step should always be coordinated with the provider’s go-live plan. 

Saudi Arabia (ZATCA – Fatoora Portal) 

Saudi Arabia’s FATOORA system, operated by the Zakat, Tax and Customs Authority (ZATCA), uses one of the most technically distinctive registration mechanisms: the Cryptographic Stamp Identifier (CSID). Instead of registering a provider’s name or code, the taxpayer cryptographically onboards each invoice generation solution, which in practice is usually the service provider’s platform acting on the taxpayer’s behalf. 

• Step 1: Generate OTPs in the Fatoora portal. The taxpayer logs into the ZATCA portal through ERAD, selects the option to onboard a new solution unit or device, and generates one-time passwords. One OTP is needed per solution unit, and each OTP is valid for only one hour, so this step is coordinated in real time with the provider. 
• Step 2: Prepare the Certificate Signing Request (CSR). The CSR configuration carries the taxpayer’s identity into the certificate: the 15-digit VAT registration number, the organization name, the solution unit identifier, the supported invoice types (standard tax invoices, simplified invoices, or both), the registered address, and the business sector. 
• Step 3: Obtain the Compliance CSID (CCSID). The CSR is submitted to ZATCA together with the OTP. ZATCA issues a Compliance CSID, which is used to run mandatory compliance checks on the invoice generation solution. 
• Step 4: Obtain the Production CSID (PCSID). Once the solution passes the compliance checks, ZATCA issues the Production CSID. This certificate is what authorizes the solution to sign and transmit live invoices. 

The key concept for taxpayers: the OTP generated in the Fatoora portal is the moment of authorization. By handing that OTP to the provider’s solution and approving the CSR data, the taxpayer formally binds the provider’s platform to its VAT identity. From that point, standard invoices are cleared by ZATCA in real time and simplified invoices are reported, all through the onboarded solution. 

Poland (KSeF – National e-Invoicing System) 

Poland’s National e-Invoicing System (KSeF) becomes mandatory in phases from February 2026, and its registration model is permission-based rather than address-based. Every action in KSeF is performed by an authenticated person or entity acting within a defined scope of permissions. 

• Step 1: Establish the first authorized person. A company that holds a qualified electronic seal containing its NIP can authenticate directly and automatically obtains owner-level rights. Companies without a seal submit the ZAW-FA notification to their tax office, designating exactly one natural person as the initial administrator of the company’s KSeF access. 
• Step 2: Grant permissions electronically. This first authorized person then grants further permissions inside KSeF, both to individuals (employees) and to entities identified by their NIP, such as an accounting office or an e-invoicing service provider. Entity-level permissions can cover issuing invoices, accessing invoices, or both. 
• Step 3: Enable technical access for the integration. For system-to-system connections, KSeF 2.0 offers two mechanisms. Authorization tokens, generated in the Certificates and Permissions Module (MCU), are 40-digit string tied to a specific entity and permission scope; they remain available only until the end of 2026. KSeF certificates are the long-term mechanism: Type 1 certificates authenticate the holder in the system, and Type 2 certificates enable offline invoice issuance. Certificates are valid for up to two years and must then be renewed. 

An important nuance that many businesses miss: a token or certificate does not create permissions, it only exercises permissions that were already granted. If the provider’s entity has not been given the correct rights first, the integration may authenticate successfully and still fail at the operation level. 

Malaysia (MyInvois Portal) 

Malaysia’s MyInvois system, operated by the Inland Revenue Board (LHDN), splits registration into two complementary actions performed in the MyTax and MyInvois portals: registering an ERP system and appointing an intermediary. 

To appoint an intermediary, which authorizes a third party to act on the taxpayer’s behalf: 

• Step 1: Log in to MyTax and open the MyInvois portal, making sure the company profile (not the individual profile) is selected. 
• Step 2: Open the Taxpayer Profile and choose Add Intermediary under the Representatives section. 
• Step 3: Enter the provider’s Tax Identification Number (TIN), business registration number (BRN), and exact registered name, then validate the details. 
• Step 4: Set the representation period (a defined start and expiration date; up to three years is common practice) and enable the specific permissions being delegated: submitting e-invoices, cancelling documents, requesting rejections, and viewing documents. 
• Step 5: Save the intermediary. The appointment appears immediately under the Intermediaries tab and can later be edited to shorten the representation period or adjust permissions. 

Registering an ERP creates the technical credentials for API integration: the taxpayer registers the ERP under Representatives, sets a secret expiration period, and receives a Client ID and secrets that authenticate against the MyInvois API. When an intermediary is appointed, submissions are signed with the intermediary’s digital certificate, so the taxpayer does not need to procure its own certificate for this channel. The legal position is worth underlining: even with an appointed intermediary, LHDN holds the taxpayer, not the provider, accountable for the accuracy and completeness of submitted e-invoices. 

Croatia (ePorezna – FiskApplication) 

Croatia’s Fiscalization 2.0 framework, covering B2B e-invoicing from 2026, introduces a two-part registration confirmation performed in the ePorezna (eTax) portal after the taxpayer registers with its chosen access point. 

• Step 1: Registration triggers an official notification. After the taxpayer completes registration on the intermediary’s platform, the Tax Administration sends a notification to the taxpayer’s ePorezna user inbox, indicating that a new address for receiving eInvoices is awaiting confirmation. 
• Step 2: Open FiskApplication. The taxpayer logs into ePorezna and selects FiskApplication in the Services menu, then opens the Administration section, which manages addresses and authorizations. 
• Step 3: Confirm the eInvoice receiving address. Under the addresses tab, the taxpayer reviews the published access point data, including the identifier (OIB) of the access point, the identifier type, and the validity date, and either confirms or rejects it. The Tax Administration explicitly advises checking the access point data carefully before confirming, since this address determines where all eInvoices will be delivered. 
• Step 4: Authorize the information intermediary for fiscalization. Under the Fiscalization Approvals tab, the taxpayer creates a new authorization: enter the intermediary’s OIB, retrieve the intermediary’s name, set the date from which the consent is valid (and optionally an end date), and save. 

Once both steps are complete, the taxpayer has a confirmed delivery address and a valid fiscalization mandate, and is ready to exchange eInvoices and submit fiscalization messages in accordance with the Fiscalization Act. 

Registering for Decentralized & Interoperable Networks 

In decentralized models there is no single government platform handling the exchange. Invoices travel across the Peppol network between certified Access Points, and the tax layer (where it exists) is added on top. Here, registering means being published on the network through your provider. 

PEPPOL Network (Germany, Belgium, the Netherlands) 

Germany (B2B e-invoicing obligations phasing in since January 2025), Belgium (mandatory Peppol-based B2B e-invoicing since 1 January 2026), and the Netherlands (long-standing Peppol infrastructure, mandatory in B2G) all rely on the same underlying registration logic. 

• Step 1: Contract with a certified Peppol service provider. The company signs a service agreement with a Peppol-certified Access Point. There is no separate government application: the Access Point is the gateway, and it performs the registration on the participant’s behalf. 
• Step 2: Receive your Peppol Participant ID. Every participant is identified by a Peppol ID composed of a four-digit scheme code and the actual identifier, separated by a colon. The scheme code tells the network which national register the identifier comes from. The most relevant schemes in these three markets are: in Belgium, 0208 for the Belgian company number issued by the Crossroads Bank for Enterprises (the baseline registration under the Belgian mandate) and 9925 for the Belgian VAT number; in Germany, 9930 for the German VAT number in B2B flows and 0204 for the Leitweg-ID used by public sector invoice recipients; in the Netherlands, 0106 for the KvK (Chamber of Commerce) number, 9944 for the Dutch VAT number, and 0190 for the OIN identifier used by Dutch public sector bodies. A company should ideally hold one primary Peppol ID, obtained the first time it is registered, although registration under multiple identifiers is common and handled by the provider. 
• Step 3: Get published on an SMP with your supported document types. To receive documents, the participant must be published on a Service Metadata Publisher (SMP). The SMP entry lists which document types the participant can receive, most importantly the Peppol BIS Billing 3.0 invoice and credit note, and in Germany additionally XRechnung-compliant profiles, together with the technical endpoint of the receiving Access Point. Senders do not need an SMP registration; publication is only required for receiving. A crucial constraint follows from this: a participant identifier can only be registered for receiving with one Access Point per document type at a time. If the company number was already published elsewhere (as happened with Belgian companies pre-registered in the government’s Hermes system), the new provider must first migrate the registration to its own SMP. 
• Step 4: Verify your entry in the Peppol Directory. Once the SMP entry is live, the participant becomes searchable in the public Peppol Directory, where any trading partner can look up the company by name or identifier and verify which document types it accepts. Appearing in the Directory is, in practice, the confirmation that the registration was completed correctly. 

United Arab Emirates (Accredited Service Providers) 

The UAE has adopted a decentralized Peppol-based five-corner model (DCTCE) using the PINT AE invoice specification, but with a mandatory twist: businesses cannot connect to the network or to the Federal Tax Authority directly. Every in-scope business, both as issuer and as recipient, must appoint an Accredited Service Provider (ASP) approved by the Ministry of Finance and the FTA. 

• Step 1: Select an ASP from the official list. The Ministry of Finance publishes the list of accredited and pre-approved service providers. Only these entities may validate invoices against PINT AE, exchange them over the network, and report tax data to the FTA. 
• Step 2: Complete the formal appointment and onboarding. The business executes the required agreement with its chosen ASP and completes onboarding, with the appointment reflected through the official channels linked to the taxpayer’s profile. Participants are addressed on the network using their Tax Identification Number under the dedicated UAE scheme (0235). 
• Step 3: Meet the binding deadlines. Businesses with annual revenue of AED 50 million or more must appoint their ASP by 30 October 2026 and go live with mandatory e-invoicing on 1 January 2027. Smaller businesses and government entities must appoint by 31 March 2027, with go-live on 1 July 2027 and, for B2G, 1 October 2027. A voluntary phase and pilot opened on 1 July 2026. 

Failing to appoint an ASP on time carries an administrative penalty of AED 5,000 for each month of delay, making the appointment itself a compliance obligation independent of invoice issuance. 

Direct Registration vs. Service Provider Integration 

Almost every system offers, at least on paper, a direct route: the free GİB portal in Turkey, direct API integration with SdI, KSeF, or MyInvois, or operating your own Peppol Access Point. In practice, the choice between direct registration and service provider integration comes down to volume, geography, and risk appetite. 

• Direct registration suits very small taxpayers with low invoice volumes who can work manually in a government portal. It requires no provider contract, but it also provides no automation, no ERP integration, and no support when schemas or validation rules change. 
• Direct API integration is technically possible for large enterprises with strong internal IT, but it means building and maintaining certified connections, signature infrastructure, and 24/7 monitoring for every country separately, and repeating that effort each time a regulation changes. 
• Service provider integration is the standard choice for automated, multi-country operations. The provider absorbs local technical differences behind a single integration, maintains compliance with schema and rule changes, and operates redundant infrastructure so invoice flows do not stop when a national platform changes or a certificate expires. The registration steps described in this guide are precisely where that delegation is made legally effective. 

The critical point applies in every model: appointing a provider commercially is not enough. Until the country-specific registration and authorization steps are completed, invoices sent through the provider may be rejected or considered non-compliant. And in every jurisdiction covered here, delegation transfers the technical execution, never the legal responsibility for the content, timing, and completeness of the invoices. 

Key Technical Requirements for a Successful Registration 

Across all these systems, a small set of technical prerequisites decides whether registration goes smoothly: 

• A valid tax identity. An active VAT or tax registration number is the anchor of every enrollment: the Partita IVA in Italy, the 15-digit VAT number in Saudi Arabia, the NIP in Poland, the TIN and BRN in Malaysia, the OIB in Croatia, and the TIN in the UAE. 
• Digital credentials. Most centralized systems require a qualified certificate or seal before registration can even begin: the financial seal in Turkey, a qualified signature or seal in Poland, and portal credentials tied to verified identities in Italy, Malaysia, Croatia, and Saudi Arabia. 
• Accurate identifiers, entered exactly. Registration steps are unforgiving about data quality. A Codice Destinatario, an intermediary’s TIN and BRN, an access point OIB, or a Peppol scheme code entered incorrectly will misroute invoices or block the authorization entirely. 
• Awareness of validity periods. OTPs in Saudi Arabia expire within one hour, Malaysian intermediary appointments run to a representation end date, Polish tokens sunset at the end of 2026 and certificates expire after two years. Every credential and mandate should be on the compliance calendar from day one. 
• Environment discipline. Most systems distinguish simulation or sandbox environments from production, sometimes with different parameter values. Completing compliance testing in the correct environment before go-live prevents rejected documents on day one. 

Common Challenges and Troubleshooting During Registration 

Certain problems come up again and again across jurisdictions: 

• Registering under the wrong profile. In Malaysia, the Add Intermediary option only appears under the company taxpayer profile, not the individual profile. In Italy, registering the telematic address against the wrong Partita IVA redirects another entity’s invoice flow. Always verify the entity context before confirming anything. 
• Existing registrations blocking new ones. On Peppol, a participant already published on another SMP (for example through Belgium’s Hermes initiative) must be migrated before the new provider can activate reception. In Italy, an already registered PEC or Codice Destinatario will be overwritten, which changes where all inbound invoices land. 
• Authentication that works but operations that fail. In Poland, a technically valid token or certificate is useless if the underlying entity permissions were never granted. Authorization errors after successful login almost always trace back to missing or mis-scoped permissions, not to the credential itself. 
• Expired one-time credentials. ZATCA OTPs are valid for one hour; generating them before the provider is ready to submit the CSR is the most common cause of failed onboarding attempts. 
• Name and identifier mismatches. Malaysian intermediary validation requires the TIN, BRN, and registered name to match exactly, including spacing conventions. Small formatting differences cause validation failures that look like system errors but are data issues. 
• Uncoordinated go-lives. Confirming a new receiving address in Croatia or Italy while the provider’s inbound processing is not yet active means legally delivered invoices arriving into an unmonitored channel. Registration timing should always be part of the provider’s cutover plan. 

FAQs About e-Invoicing Registration 

How long does the registration process typically take? 

The portal steps themselves usually take minutes: registering a Codice Destinatario, adding an intermediary in MyInvois, or confirming an address in ePorezna. The full project takes longer because of prerequisites: obtaining a financial seal or qualified certificate can take days to weeks, ZATCA compliance checks must be passed before production certificates are issued, and Peppol SMP migrations depend on the previous provider. Realistically, businesses should plan days to a few weeks end to end, which is why authorities such as the UAE set the appointment deadline months before the go-live date. 

Do I need to register again if I change my accounting software? 

Usually you do not repeat the full registration, but you almost always need to update the delegation. Changing your provider means registering a new Codice Destinatario in Italy, appointing a new intermediary and ERP in Malaysia, granting permissions to the new entity in Poland, confirming a new receiving address in Croatia, migrating your Peppol SMP entry to the new Access Point, or onboarding new solution units with fresh CSIDs in Saudi Arabia. Your enrollment as a taxpayer persists; the technical authorization attached to it does not. 

Can I register for e-invoicing in multiple countries simultaneously? 

Yes, and multinational groups routinely do. Each country’s registration is independent and must be completed in its own portal or network, with its own credentials and identifiers. Working with a single provider that is certified or accredited across all relevant jurisdictions allows the registrations to run in parallel behind one integration, but it does not merge them: a Peppol registration in Belgium does not enroll you in KSeF, and a MyInvois intermediary appointment has no effect in the UAE. Central coordination of identifiers, credentials, and expiration dates is what makes multi-country registration manageable. 

---