A retail eInvoicing project is a data-and-system project, not only an invoice-template update.
A retailer may issue hundreds of receipts and invoices every day, but UAE eInvoicing is not simply a new layout for those documents. It changes how invoice data is structured, validated, exchanged and reported.
The same business may handle a walk-in consumer sale, a corporate gift order, a government order, an online refund and a supplier invoice. Each flow can begin in a different system. The readiness challenge is to classify the transaction correctly and keep the required data connected from the original order to the final invoice or credit note.
DIRECT ANSWER — UAE eInvoicing is the structured electronic exchange of invoice data between supplier and buyer through accredited channels, with relevant tax data reported electronically to the Federal Tax Authority. A PDF, Word file, image, scan or email is not an eInvoice. Retailers should confirm scope and timing, clean data, select an Accredited Service Provider, map systems and test invoices, credit notes and rejected documents before go-live.
Source and scope check — Regulatory sources were reviewed on 16 September 2026. The Ministry of Finance says its eInvoicing portal is the official programme source and may evolve. Check the live portal and decisions before making a compliance decision for your own business; this guide is operational education, not legal, tax or accounting advice.
In this guide
What counts as an eInvoice and why a PDF is not enough
Which retail transactions fall into the published B2B and B2G scope
The current rollout dates and the first-phase deadline change
How the UAE four-corner exchange and tax-reporting model works
Which legal, buyer, supplier, item, tax and document data to prepare
How to map ecommerce, POS, manual orders, refunds, purchases and accounting
How to select an Accredited Service Provider and divide responsibilities
A six-stage implementation roadmap, testing matrix and readiness scorecard
Where Bloomlytix can support the readiness discussion—and what is not confirmed scope
1. An eInvoice is structured data—not a digital-looking invoice
The UAE Ministry of Finance and Federal Tax Authority define an eInvoice as structured invoice data that is issued and exchanged electronically between a supplier and a buyer and reported electronically to the FTA. That definition is about machine-readable data and a controlled exchange process.
A PDF can still be useful for a person who wants to read or print the invoice. But sending that PDF by email does not turn it into an eInvoice under the UAE programme. The structured document must carry the required fields in the approved format and move through the defined network.
Figure 1. A readable representation may still exist, but the regulated eInvoice is the structured data flow.
QUESTION | PDF / EMAIL ATTACHMENT | STRUCTURED UAE EINVOICE |
|---|---|---|
Main purpose | Easy for a person to view, print or store. | Allows systems to validate, exchange and process invoice data automatically. |
Format | Usually an unstructured document or image. | Structured data aligned to the UAE standard and current mandatory-field rules. |
Exchange | Sent directly by email, portal upload or another manual route. | Exchanged through the appointed Accredited Service Providers. |
Tax reporting | Does not itself complete the UAE eInvoicing reporting process. | Relevant tax data is reported electronically through the programme model. |
Status feedback | A delivered email does not prove the invoice data was accepted. | Validation and message-level statuses show whether the document moved successfully. |
PRACTICAL RULE — Do not start by redesigning the invoice PDF. Start by finding where each required data field comes from, who owns it, how it reaches the ASP and what the team does when validation fails.
Official sources: Ministry of Finance eInvoicing portal · Federal Tax Authority eInvoicing page
2. Confirm the published scope before changing the workflow
The published UAE scope applies to persons conducting business in the UAE for business-to-business (B2B) and business-to-government (B2G) transactions, subject to the exclusions set out in the official decisions. The decisions also allow voluntary use in some situations outside mandatory scope.
For a retailer, the difficult part is that the same catalogue and counter can support different transaction types. A normal consumer purchase is not the same flow as a corporate bulk order. The system should identify the buyer type before it generates the document—not after the sale is complete.
Figure 2. One retailer can have consumer, corporate, government, refund and supplier-invoice journeys.
RETAIL SITUATION | READINESS QUESTION | OPERATIONAL ACTION |
|---|---|---|
Walk-in or online consumer sale | Is this a B2C transaction rather than a B2B/B2G document? | Keep the correct POS/VAT document flow and classify it separately from the published B2B/B2G mandate. |
Corporate order | Do we have the buyer’s legal identity, tax identifiers, electronic address and reference data? | Capture business-buyer fields before confirming the invoice. |
Government order | Which government entity and reference requirements apply? | Confirm the buyer record, purchase reference and B2G process with the adviser and ASP. |
Cancellation, refund or price reduction | Does the original in-scope transaction require an electronic credit note? | Keep the credit note linked to the original invoice and the related commercial event. |
Supplier purchase | Can accounts payable receive and process the supplier’s eInvoice and credit notes? | Prepare inbound validation, matching, exception and storage processes—not only outbound invoices. |
SCOPE CAUTION — Do not use revenue threshold as the only scope test. Legal entity, transaction type, invoice obligation, exclusions and implementation phase all matter. Ask a qualified UAE tax adviser to confirm the exact position.
Official sources: Ministry of Finance scope announcement · Ministerial Decision 244 of 2025
3. Current UAE eInvoicing timeline for retailers
The rollout is phased. The pilot began on 1 July 2026. The first mandatory phase starts in 2027. The Ministry later extended the first group’s deadline for appointing an ASP while keeping its implementation date unchanged.
Current published timetable — The table reflects the Ministry decisions available on 16 September 2026. Decision 66 of 2026 extends the first group’s ASP appointment deadline; an older table in the Ministry’s June guidelines still shows the superseded July date.
GROUP | ASP APPOINTMENT DEADLINE | MANDATORY IMPLEMENTATION |
|---|---|---|
Businesses with annual revenue of AED 50 million or more | 30 October 2026 (extended from the original first-phase appointment date) | 1 January 2027 |
Businesses below AED 50 million annual revenue | 31 March 2027 | 1 July 2027 |
In-scope government entities | 31 March 2027 | 1 October 2027 |
The deadline is not the project start date. A retailer still needs time to select an ASP, agree commercial terms, clean master data, map the source systems, build or configure the connection, test normal and exception scenarios, train users and establish monitoring.
Retailers near the revenue threshold or operating through several legal entities should not classify themselves from this summary. Confirm which entity, revenue basis and mandatory phase apply through the official decisions and qualified advice.
Official sources: Ministerial Decision 66 of 2026 · Ministerial Decision 244 of 2025
4. How the UAE eInvoicing model works
The business exchange is commonly described as a four-corner model: supplier, supplier’s ASP, buyer’s ASP and buyer. The UAE programme also includes a fifth reporting corner for tax data and status messages. This is why an invoice template alone cannot complete the process.
Figure 3. The supplier and buyer exchange the eInvoice through their ASPs while tax data is reported through the fifth corner.
CORNER | ROLE | RETAIL READINESS QUESTION |
|---|---|---|
C1 — Supplier | Creates the invoice from its order, finance or billing data. | Which system owns the final invoice number, buyer, lines, tax and original transaction reference? |
C2 — Supplier ASP | Validates, converts where needed, exchanges the eInvoice and reports tax data. | How will POS/ecommerce/accounting data reach the ASP, and how will errors return? |
C3 — Buyer ASP | Receives and validates the eInvoice for the buyer. | Can inbound supplier documents enter accounts payable and matching controls? |
C4 — Buyer | Receives the eInvoice in the agreed business format. | Who reviews mismatches, rejected documents and duplicate or corrected invoices? |
C5 — Tax reporting | Receives the required tax data documents and sends status messages. | How will reporting status be monitored and retained with the business record? |
The Ministry of Finance says businesses can select an accredited provider through EmaraTax, enter a commercial agreement and complete onboarding. The provider relationship is part of the operating model, but it does not remove the retailer’s responsibility for correct source data, classifications and internal controls.
Official sources: Ministry of Finance model overview · four-corner launch
5. Prepare the data before selecting the final integration design
An ASP can validate and exchange structured data only when the business systems supply the right values. If the buyer record is incomplete, the item tax category is unclear or a credit note has no original invoice reference, technology cannot safely guess the missing business fact.
Figure 4. Build a source-of-truth map for each data group before technical integration begins.
DATA GROUP | EXAMPLES TO PREPARE | OWNER QUESTION |
|---|---|---|
Legal entity | Legal name, relevant registrations, TIN/TRN where applicable, addresses and entity status. | Which legal entity is the supplier for each branch, website, marketplace or POS sale? |
Buyer and supplier master | Legal name, identifiers, tax details, electronic address, billing address and contact/reference data. | Do we collect business-buyer data before the invoice is generated? |
Document identity | Invoice or credit-note number, issue date/time, document type, currency, payment terms and original references. | Which system creates the official number, and can it prevent duplicates? |
Line details | Product/service description, quantity, unit, unit price, discounts, charges and item reference. | Can one POS or online line be translated into the required structured fields? |
Tax details and totals | Tax category, rate, taxable amount, tax amount, allowances/charges and final totals. | Which values come from approved tax configuration rather than manual entry? |
Lifecycle and status | Submitted, validated, rejected, accepted, corrected, credited, archived and notification history. | Who owns a rejected or delayed document and how is the final outcome linked to the order? |
NOT AN EXHAUSTIVE FIELD LIST — The official mandatory-field document and the final ASP mapping are the source of truth. The table above is an operational readiness checklist, not a replacement for the current UAE data specification.
Official sources: official mandatory-field requirements · Ministry of Finance programme portal
6. Map every source system and transaction touchpoint
Retail eInvoicing usually fails at the handoffs between systems. The ecommerce site knows the customer and delivery details. The POS knows the counter sale. The order platform knows the refund. The accounting system may create the tax document. The ASP needs one consistent, approved data package.
SYSTEM OR PROCESS | DATA IT MAY OWN | READINESS DECISION |
|---|---|---|
Ecommerce website / customer app | Product, buyer, delivery, order, discounts and online payment context. | Which buyer fields become mandatory when a customer identifies as a business? |
POS | Branch, cashier, items, price, tax, payment and receipt/invoice request. | Can staff distinguish consumer, corporate and government buyers before closing the sale? |
Manual / WhatsApp / corporate orders | Agreed products, custom lines, buyer reference, payment and delivery promise. | How does an assisted sale become one structured order instead of a chat and separate invoice? |
Order management | Fulfilment, cancellation, return, refund, delivery and order timeline. | Which commercial event triggers an electronic credit note, and who approves it? |
Accounting / ERP | Official invoice, tax configuration, customer ledger, credit note and reporting. | Is this the invoice source of truth, or will another system create the document? |
Supplier purchasing / accounts payable | Supplier, purchase order, goods receipt, invoice, tax, matching and payment. | Can inbound eInvoices be received, matched, rejected or held with a reason? |
Accredited Service Provider | Validation, transformation, exchange, reporting and message statuses. | Which connection method, fields, callbacks, logs and support responsibilities are included? |
SOURCE-OF-TRUTH RULE — Name one system as the owner for each important field: legal entity, buyer, invoice number, line value, tax, credit-note reference and document status. Two systems should not silently edit the same field without a conflict rule.
7. Select an Accredited Service Provider with operational questions—not only price
The Ministry of Finance publishes a list of fully accredited ASPs and a separate list of providers that are still under final assessment. Because the list is updated, check the provider’s current official status on the date you sign the contract.
SELECTION AREA | QUESTIONS TO ASK THE ASP |
|---|---|
Accreditation | Are you fully accredited today? What is the accreditation number, legal entity and scope of service? |
Connection | Do you support API, file, connector or another method for our exact POS, ecommerce and accounting setup? |
PINT AE and mapping | Who maps our source fields to the UAE structure, maintains code lists and manages future specification changes? |
Outbound and inbound | Can you support both invoices we issue and documents we receive from suppliers? |
Validation and rejection | Which checks happen before sending? How do staff see, correct and resubmit a rejected document? |
Security and access | How are encryption, authentication, user access, audit logs, data retention and business continuity handled? |
Testing and cutover | What sandbox, test cases, volume testing, sign-off and go-live support are included? |
Support and SLA | Who owns incidents, which hours are covered and how are reporting failures escalated? |
Commercial terms | What are setup, subscription, transaction, support, change, storage and exit costs? |
Data portability | Can we export invoice data, statuses and evidence if we change ASP or software provider? |
DO NOT CONFUSE ROLES — Your ecommerce, POS or retail operating platform may create the business transaction data. The ASP provides the accredited exchange and reporting layer. The tax adviser confirms the business interpretation. These roles must be connected, but they are not interchangeable.
Official sources: current accredited ASP list
8. Give every implementation role a named responsibility
ROLE | MAIN RESPONSIBILITY | EVIDENCE OF COMPLETION |
|---|---|---|
Executive sponsor | Approve scope, budget, priorities and risk decisions. | Named project owner, steering rhythm and escalation path. |
Finance / tax lead | Confirm transaction scope, document rules, tax treatment and adviser decisions. | Approved scope memo and signed field/rule mapping. |
Qualified UAE tax adviser | Review legal and tax interpretation, exclusions, deadlines and edge cases. | Written advice for the business’s entities and transaction types. |
Accredited Service Provider | Provide accredited exchange, mapping support, validation, testing and status handling. | Contract, solution design, test evidence and support model. |
Retail software / ERP team | Expose correct source data, connect APIs/files, store statuses and support exceptions. | Technical mapping, interfaces, logs and acceptance tests. |
Operations / POS / ecommerce owner | Define how staff identify buyer type, create orders, issue credit notes and correct errors. | Updated SOPs and role-based training. |
Data owner | Clean legal entities, buyers, suppliers, items, tax codes and references. | Approved master-data quality report. |
QA / support owner | Run scenarios, track defects and own rejected or delayed documents after launch. | Test pack, defect closure and incident playbook. |
GOVERNANCE RULE — Do not let “the software team” own every question. Software can move approved data; it cannot decide which legal entity, tax treatment, exclusion or buyer classification is correct for the business.
9. Follow a six-stage readiness roadmap
Figure 5. The stages overlap, but scope and data decisions must be stable before final testing.
Stage 1 — Confirm scope and timeline
List every legal entity, revenue group, sales channel and transaction type. Mark B2B, B2G, B2C, self-billing, credit notes and any potential exclusion. Ask the adviser to confirm the result and mandatory date.
Stage 2 — Clean the master data
Validate legal names, identifiers, customer and supplier records, electronic addresses, items, units, prices, tax categories, currencies and reference fields. Remove duplicates and define who can change each field.
Stage 3 — Select and contract the ASP
Use the current official accreditation list. Compare connection design, mapping support, inbound/outbound scope, security, testing, pricing, SLA and exit terms.
Stage 4 — Map the systems and controls
Document how POS, ecommerce, manual orders, refunds, accounting, supplier invoices and the ASP exchange data. Define invoice numbering, credit-note links, statuses, logs and ownership when an interface fails.
Stage 5 — Test normal and exception scenarios
Use realistic transactions and incomplete data. Test validation, rejection, correction, duplicate protection, credit notes, system outage, inbound invoices, user permissions and audit evidence.
Stage 6 — Go live with monitoring
Train users, publish the SOP, monitor status queues, reconcile document counts and values, review rejected items daily and keep a controlled change process for new fields, branches and transaction types.
10. Test the difficult retail scenarios before go-live
SCENARIO | EXPECTED CONTROL | FAILURE THIS TEST CAN REVEAL |
|---|---|---|
Standard B2B sale from ecommerce | Business buyer data, invoice lines, tax and status move through the approved path once. | Missing buyer fields, wrong entity or duplicate submission. |
Corporate sale created at POS | Cashier selects the business buyer before closing and the correct document path starts. | A B2B sale recorded as a normal consumer receipt. |
B2G order | Government buyer and required references are complete before transmission. | Rejected document or manual rework after delivery. |
Partial refund / price reduction | The payment action, order outcome and linked electronic credit note remain connected. | Refund issued without the correct document or original reference. |
Cancelled order before fulfilment | The cancellation reason and any required credit note are created once. | Duplicate reversal, wrong status or missing financial evidence. |
Buyer identifier missing | The document is held for correction instead of being sent with guessed data. | Rejected invoice and unreliable customer master data. |
ASP validation rejection | The error reaches a named queue with field-level context and resubmission control. | Staff cannot see why the document failed or sends it twice. |
Network or source-system outage | Transactions queue safely, alerts trigger and the recovery process prevents duplicates. | Lost documents, late reporting or uncontrolled manual work. |
Inbound supplier invoice mismatch | Accounts payable can compare supplier, reference, line/tax totals and receipt/purchase context. | Duplicate payment or unresolved purchase variance. |
High-volume day | The connection processes realistic volume while status monitoring remains usable. | Backlog, timeout or slow error recovery at peak demand. |
11. Common readiness mistakes
MISTAKE | WHY IT CREATES RISK | BETTER ACTION |
|---|---|---|
Treating eInvoicing as a PDF redesign | The structured fields, network exchange and status flow remain unsolved. | Map the data and system journey first. |
Leaving the project only with accounting | Buyer classification, POS, ecommerce, refunds and operations also create invoice data. | Use a cross-functional project team. |
Waiting for the ASP to clean business data | The provider cannot safely invent entity, buyer, item or tax facts. | Complete master-data ownership and cleanup early. |
Ignoring inbound supplier documents | The business prepares to send invoices but cannot receive or match them. | Design accounts-payable readiness at the same time. |
Treating a refund as the complete credit-note process | Money movement and invoice correction are related but different controls. | Link the commercial event, payment outcome and electronic credit note. |
No owner for rejections | Documents stay failed while staff assume the invoice was sent. | Create a monitored exception queue and escalation SLA. |
Using an outdated date or ASP list | The programme and provider list continue to evolve. | Check official sources at contract, testing and publication dates. |
12. Current enforcement context
The UAE has published administrative fines for entities that are required to implement the system. The official announcement includes a monthly fine for failure to implement or appoint an ASP by the deadline, per-document fines for missing electronic invoices or credit notes, and daily fines for delayed notifications of system failures or registered-data changes.
PUBLISHED VIOLATION SUMMARY | PUBLISHED ADMINISTRATIVE FINE |
|---|---|
Failure to implement the system or appoint an ASP within the required timeframe | AED 5,000 per month |
Electronic invoice not issued or sent within the required timeframe | AED 100 per document, capped at AED 5,000 per month |
Electronic credit note not issued or sent within the required timeframe | AED 100 per document, capped at AED 5,000 per month |
Delay in notifying the FTA of a system malfunction | AED 1,000 for each day of delay or part of a day |
Delay in notifying the appointed ASP of a change to registered data | AED 1,000 for each day of delay or part of a day |
Read the original decision — These are published administrative-fine summaries for entities that are required to implement the system. The official Cabinet Decision and your circumstances control; use qualified advice rather than this summary to assess exposure.
Official sources: Ministry of Finance administrative-fines announcement
13. How Bloomlytix can support a readiness conversation
Bloomlytix is designed as a connected ecommerce and retail operations platform. Its verified scope includes ecommerce, customer apps where included, POS, order fulfilment, payments, inventory, purchase records, cash tracking, delivery and reports. The POS can generate receipts or invoices, while purchase records can store supplier, branch, category, subtotal, VAT, total and supporting evidence.
Those operational records can support a readiness assessment because they reveal where the source data begins and how orders, payments, cancellations, refunds, purchases and branches are connected. The implementation discussion should then identify which fields already exist, which need cleanup and which external components are required. See Bloomlytix platform features for the published module scope.
CONFIRMED OPERATIONAL AREA | READINESS USE | NEEDS WRITTEN CONFIRMATION / SEPARATE SCOPE |
|---|---|---|
Website, apps, POS and manual orders | Map the source channel, buyer, items, price, tax, branch, payment and order status. | Final B2B/B2G classification rules and mandatory eInvoice field completeness. |
Order cancellations and refunds | Identify the event that may require a linked credit note and preserve the timeline. | Automatic compliant electronic credit-note creation and transmission. |
Purchase invoices and supplier records | Review inbound supplier, branch, subtotal, VAT, total and evidence. | Receiving structured supplier eInvoices through an ASP and accounts-payable integration. |
Reports and exports | Compare document counts, sales, refunds, branches and operational exceptions. | Regulatory archive, PINT AE payload, tax reporting and official status evidence. |
Custom integration option | Scope connections outside the standard platform when technically and commercially agreed. | ASP connector, accreditation, certification, compliance or any specific government integration. |
Product scope — Bloomlytix is a retail operations platform, not an Accredited Service Provider or a certified UAE eInvoicing solution. Any ASP connection, PINT AE mapping, mandatory-field coverage, electronic credit-note transmission, reporting or compliance claim requires separate written scope and testing.
BRING ONE REAL WORKFLOW — Use one real UAE B2B order and one cancellation, refund or credit-note example. We can map where Bloomlytix holds the operational data, which questions the ASP must answer and which items require adviser or integration confirmation.
Book a Bloomlytix readiness conversation
14. Questions to ask your software provider and ASP
Which system creates the official invoice and credit-note number?
How are B2B, B2G and B2C transactions identified before the sale is closed?
Which current UAE mandatory fields can each source system supply, and which are missing?
How are buyer and supplier identifiers validated and kept current?
How is data mapped to PINT AE and updated when specifications change?
Which ASP connection method is supported, and who owns it after go-live?
How are validation, exchange and tax-reporting status messages returned to staff?
What happens when a document is rejected, duplicated, delayed or corrected?
How are refunds, cancellations and price reductions linked to electronic credit notes?
Can inbound supplier eInvoices be received, matched, held and exported?
What logs, evidence, retention, security and business-continuity controls are included?
Which parts are standard, custom, third-party or still unconfirmed—and what will each cost?
15. UAE eInvoicing Retail Readiness Scorecard
Score each area only after it is shown in a document, data sample, contract, system demonstration or approved test. Use 0 for not confirmed, 1 for partial or dependent on extra work, and 2 for confirmed and owned.
READINESS AREA | PASS CONDITION | SCORE 0–2 |
|---|---|---|
Scope and legal entities | B2B/B2G flows, exclusions, entities and mandatory dates are confirmed. | |
Transaction classification | POS, ecommerce and assisted orders identify B2C, B2B and B2G correctly. | |
Buyer and supplier data | Legal names, identifiers, addresses and required electronic details are complete. | |
Product, tax and totals | Line, unit, price, discount, tax and total data come from controlled sources. | |
Invoice and credit-note lifecycle | Numbers, original references, cancellation, refund and correction rules are defined. | |
ASP appointment | A currently accredited ASP is selected with signed scope, price and support terms. | |
System mapping | POS, ecommerce, order, accounting and ASP responsibilities are documented. | |
Inbound documents | Supplier eInvoice receipt, matching, rejection and storage are designed. | |
Testing | Normal, rejection, correction, duplicate, outage, credit-note and volume tests have passed. | |
Monitoring and ownership | Queues, alerts, logs, incident owners and daily review are ready. | |
Training and SOPs | Cashiers, finance, customer service and support know their decisions and escalation path. | |
Regulatory verification | A qualified adviser and current official sources have approved the final interpretation. |
TOTAL | INTERPRETATION | NEXT ACTION |
|---|---|---|
20–24 | Strong implementation readiness | Close remaining defects, complete final regulatory check and proceed through controlled go-live approval. |
13–19 | Partial readiness | Resolve data, scope, ASP, integration or testing gaps before committing to go-live. |
0–12 | High implementation risk | Stop relying on assumptions; assign owners and complete a formal readiness assessment. |
Frequently asked questions
Is a PDF invoice an eInvoice in the UAE?
No. The official UAE definition requires structured invoice data exchanged electronically and reported through the programme. A PDF, scan, image, Word file or email is not an eInvoice by itself.
Which UAE transactions are in the published scope?
The published mandatory scope covers B2B and B2G transactions for persons conducting business in the UAE, subject to official exclusions. Confirm the exact treatment of your entities and transactions with a qualified adviser.
What is an Accredited Service Provider?
An ASP is a provider accredited by the Ministry of Finance to support the UAE eInvoicing exchange and reporting model. Businesses appoint an ASP and connect their source systems and processes to it.
When must retailers implement UAE eInvoicing?
The current phased timetable begins on 1 January 2027 for the first business group, followed by 1 July 2027 for businesses below the AED 50 million annual-revenue threshold. Government entities follow on 1 October 2027. Check the current official decisions before acting.
Does every retailer need to replace its POS or accounting system?
Not automatically. An existing system may remain the source of invoice data if it can supply complete, controlled information and connect reliably to the ASP model. The decision depends on gaps, integration capability and total implementation risk.
Do B2C retail sales follow the same eInvoicing flow?
The published mandatory scope is B2B and B2G. Retailers still need to classify transactions correctly and continue the applicable POS, VAT and record-keeping processes for consumer sales.
Does Bloomlytix currently claim UAE eInvoicing compliance?
No such claim is made in this article. Bloomlytix can support operational data mapping and a technical readiness conversation. Any ASP integration, mandatory-field coverage, certification or compliance statement requires written confirmation and testing.
Final readiness checklist
The official MoF portal and decisions have been checked for current scope, dates and exclusions.
Every legal entity and mandatory phase has a written adviser-confirmed position.
B2B, B2G and B2C transactions can be identified before the document is generated.
Legal-entity, buyer, supplier, item, tax, total and reference data have named owners.
Invoice numbers and credit-note links have one source of truth and duplicate protection.
A currently accredited ASP has been selected from the official list.
The ASP contract clearly covers mapping, inbound/outbound flow, security, testing, support and exit.
Ecommerce, POS, manual orders, refunds, accounting and supplier purchases are mapped end to end.
Rejected, delayed, corrected and duplicate documents have a visible queue and owner.
Normal, credit-note, missing-data, outage, inbound and volume scenarios have passed testing.
Staff SOPs, permissions, escalation and monitoring routines are ready before go-live.
Bloomlytix and every other software provider has documented what is standard, custom or unconfirmed.
Official UAE sources used
Regulatory sources reviewed on 16 September 2026. Check the live Ministry portal before acting.
Ministry of Finance eInvoicing portal — definition, model, decisions and guidance
Federal Tax Authority eInvoicing page — definition and legislation
Ministerial Decision 244 of 2025 — pilot, voluntary use, B2C exclusion and phases
Ministerial Decision 66 of 2026 — amended first-group ASP deadline
