Albania — the « Fiskalizimi » fiscalization and real-time invoice clearance

Since 2021, Albania has run one of the most comprehensive fiscalization regimes outside the EU. Under Law no. 87/2019, every invoice — B2G, B2B or B2C — must be reported in real time to the tax administration at or before delivery, through the Central Invoice Platform (Platforma Qendrore e Faturave, PQF). The system, known as « Fiskalizimi », is designed to close the VAT gap and curb the informal economy by assigning every transaction a unique identifier that the buyer can verify.

Context & legal framework

Albania's regime rests on Law no. 87/2019 « On the invoice and turnover monitoring system », passed in December 2019. It establishes the mandatory electronic invoice and a real-time turnover-monitoring system, fleshed out by several Council of Ministers decisions and Ministry of Finance instructions.

The objective is explicitly fiscal: shrinking the VAT gap, formalising the economy and giving the administration transaction-by-transaction visibility.

• Primary regulator: the General Directorate of Taxation (Drejtoria e Përgjithshme e Tatimeve, DPT) — the central tax administration.
• Technical partner: AKSHI (National Agency for Information Society), which issues the electronic signing certificates and runs the identity infrastructure via the e-Albania portal.

Scope is broad: every registered taxable person holding a NIPT (Albanian tax ID) must fiscalize all of its invoices, cash sales included. Penalties bite: an unfiscalized invoice can trigger a fine of roughly ALL 50,000 (~EUR 500) for an individual and up to ALL 500,000 for a legal entity on repeat offences.

Regulatory timeline

Note: the 2026 deadlines concern payment acceptance and hardware, and complement — they do not replace — the fiscalization obligation in force since 2021.

Format & technical schema

The Albanian electronic invoice is a structured XML document. The PQF accepts two schema families:

• UBL 2.1 — Universal Business Language, standardised as ISO/IEC 19845:2015 (the most common format);
• UN/CEFACT Cross-Industry Invoice (CII) — XML Schema 16B.

The payload carries the expected blocks of a compliant invoice — supplier and buyer identity (NIPT), line items, VAT breakdown, totals — plus the Albanian specificity: a fiscalization block bearing the issuer identifier NSLF and, once cleared, the NIVF returned by the platform.

Illustrative excerpt (simplified, UBL 2.1):

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
  <cbc:ID>2026/00148</cbc:ID>
  <cbc:IssueDate>2026-06-23</cbc:IssueDate>
  <cbc:InvoiceTypeCode>388</cbc:InvoiceTypeCode>
  <cbc:DocumentCurrencyCode>ALL</cbc:DocumentCurrencyCode>
  <cac:AccountingSupplierParty>
    <cac:Party>
      <cac:PartyTaxScheme>
        <cbc:CompanyID>L72345678A</cbc:CompanyID> <!-- supplier NIPT -->
      </cac:PartyTaxScheme>
    </cac:Party>
  </cac:AccountingSupplierParty>
  <!-- Albanian fiscalization block -->
  <cac:AdditionalDocumentReference>
    <cbc:ID>NSLF</cbc:ID>
    <cbc:DocumentDescription>A1B2C3D4E5F6...</cbc:DocumentDescription>
  </cac:AdditionalDocumentReference>
  <cac:AdditionalDocumentReference>
    <cbc:ID>NIVF</cbc:ID>
    <cbc:DocumentDescription>f8d2...-returned-by-the-PQF</cbc:DocumentDescription>
  </cac:AdditionalDocumentReference>
</Invoice>

Electronic signature: every invoice must be electronically signed using the certificate issued by AKSHI. It is this signature, applied by the issuer's software or fiscal device, that produces the NSLF.

Transmission flow

Albania uses real-time clearance (continuous transaction control): an invoice is only legally valid once the platform has acknowledged it. Two identifiers bracket the flow.

• NSLF (Numri i Sigurisë i Lëshuesit të Faturës — issuer security code): computed locally by the issuer's software/fiscal device from the electronic signature, before submission. It uniquely identifies the document on the issuer side.
• NIVF (Numri Identifikues i Veçantë i Faturës — unique invoice identification number): assigned by the PQF and returned in response, typically within a few seconds, evidencing that the invoice is declared and authorised.

Typical sequence:

1. The issuer software builds the XML invoice, signs it with the AKSHI certificate and derives the NSLF.
2. The invoice is sent to the Central Invoice Platform (PQF) via API (web service), with authentication anchored on the certificate and the e-Albania identity.
3. The platform validates and returns the NIVF (or a reasoned rejection).
4. The issuer prints NIVF, NSLF and a QR code on the invoice/receipt handed to the customer.
5. The customer can verify authenticity by scanning the QR code, which queries the DPT central system.

For low-volume operators, a simplified fiscalization procedure exists: keying invoices directly into the PQF Self-Care portal, with no dedicated software to install.

Validation & compliance

An invoice is compliant only once it has cleared all PQF checks.

• Structural validation: conformance to the XML schema (UBL 2.1 or CII 16B) — a malformed document is rejected.
• Signature validation: the electronic signature must be valid and backed by a current AKSHI certificate.
• Business consistency: valid NIPTs, correct VAT breakdown, coherent totals.
• Acknowledgement: only obtaining the NIVF counts as proof of declaration. Without a NIVF, the invoice is deemed unfiscalized.

Prerequisites to issue:

• Internet access at the point of invoicing;
• an AKSHI electronic certificate;
• access to the PQF via e-Albania credentials (NIPT + password).

Archiving: invoices must be kept electronically for five full years from the year following their issuance.

On the vendor side, software solutions must be certified by DPT and AKSHI; 30+ providers are approved, and version updates must be declared within set deadlines.

Common pitfalls

• AKSHI certificate lead times: in peak periods, issuance of the electronic certificate can take several weeks. Plan ahead before any registration or go-live deadline.
• Confusing NSLF and NIVF: the NSLF is produced locally by the issuer before sending; the NIVF only exists after the platform acknowledges it. An invoice with an NSLF but no NIVF is not fiscalized.
• Real-time dependency: an internet outage blocks clearance. Have a fallback procedure and a way to regularise invoices issued in degraded mode.
• Missing or unreadable QR code: the QR code is mandatory on the document handed to the customer and underpins verifiability; its absence is non-compliance.
• Under-scoping B2C/cash: unlike some EU regimes, Albania also fiscalizes cash sales to consumers since September 2021 — and imposes a POS/POI equipping schedule completing by end-2026.
• Non-certified or outdated software: only DPT/AKSHI-certified solutions are accepted; updates must be declared on time or submissions are rejected.
• Reusing e-invoice data for VAT: since April 2025, VAT returns are pre-filled from fiscalized invoices — any mis-declared invoice flows straight into the return.

Cross links

• The regime's pivot format: UBL (Universal Business Language), in version 2.1 (ISO/IEC 19845:2015).
• Alternative accepted XML format: the UN/CEFACT CII profile — see also the UN/CEFACT exchange context in EDIFACT.
• To understand interoperable transmission models in Europe: Peppol.
• Definitions of key concepts (clearance, CTC, NIPT, electronic signature): glossary.
• Compare with other national regimes: all countries.