# E-invoicing for transport companies: what you need to know

> E-invoicing explained for transfer and transport companies: clearance vs reporting, UBL XML, hash chains, QR codes, credit notes, VAT returns and what to ask your vendor.

https://transferarc.com/blog/e-invoicing-transport-companies

More and more tax authorities require invoices to be issued electronically, in a structured format, and often approved before the customer receives them. For transfer companies issuing hundreds of invoices a day, this has to be automatic. Here is how e-invoicing works and what to look for.

## What e-invoicing is (and is not)

A PDF sent by email is an electronic document, but it is not an e-invoice in the regulatory sense. An e-invoice is a **structured data file**, usually XML, that a tax authority’s systems can read automatically: seller, buyer, lines, tax rates, totals and identifiers in defined fields. The human-readable PDF becomes a copy of that data, not the original.

Governments introduce e-invoicing to close the VAT gap: when every invoice is reported in real time, under-declared sales become visible. Saudi Arabia, Egypt, India, Malaysia and several European countries already require or are phasing in e-invoicing, and others have announced their own programmes. A transport company expanding across borders should expect it everywhere sooner or later.


## Clearance vs reporting

Countries use two broad models, and many use both depending on the customer type:

| Model | How it works | Typical use |
| --- | --- | --- |
| Clearance | The invoice is sent to the tax authority and must be approved before it is issued to the customer. | Business-to-business (B2B) invoices. |
| Reporting | The invoice is issued to the customer first and reported to the tax authority within a deadline. | Business-to-consumer (B2C) invoices. |

For a transfer company, that usually means agent and corporate invoices are cleared, while invoices to individual passengers are reported. Your software has to know which is which and handle both, including retries when the tax authority’s system is slow or unavailable.


## The building blocks of a compliant e-invoice

- **Structured format:** commonly UBL 2.1 XML, the international standard many countries build on.
- **Hash chain:** each invoice includes a cryptographic hash of the previous one, so invoices cannot be deleted or inserted later without detection.
- **Digital signature:** the invoice is signed with a certificate issued to your company.
- **QR code:** printed on the visible invoice so anyone can verify it.
- **Credit and debit notes:** corrections are new documents linked to the original invoice, never edits.
- **Archive format:** often PDF/A-3, which can embed the original XML inside the PDF for long-term storage.


## Why transport companies find e-invoicing hard

Transfer operations generate invoicing edge cases most retail businesses never see:

- Bookings amended several times before the trip, each change affecting the price.
- Cancellation fees and no-show charges after the trip should have happened.
- Agent bookings invoiced monthly in one consolidated invoice.
- Cash collected by drivers that must still be invoiced and taxed correctly.
- Multi-leg and group bookings where legs complete on different days.

If invoicing lives in a separate accounting package, someone has to translate each of these into invoices by hand, and every manual step is a compliance risk. When invoicing is generated from the booking itself, the invoice, credit notes and journals follow the operation automatically.


## Connecting e-invoices to the ledger and VAT return

An e-invoice is only half the story. The same transaction must appear in your ledger and in your VAT or GST return, with matching amounts. The cleanest approach is a platform where completing a trip recognises revenue and output tax, the invoice is produced from that same record, and the tax return is built from the ledger and compared against it. TransferArc’s [accounting and e-invoicing module](https://transferarc.com/accounting) works this way: invoices, credit notes and debit notes are produced as UBL 2.1 XML with a hash chain, signature and QR code, cleared or reported where required, and archived as bilingual PDF/A-3 with the XML embedded.

> **Tax point matters.** VAT is usually due at the earlier of payment or supply. Prepaid transfers can create a tax point before the trip happens, so the system must handle tax on payment and on completion correctly.


## Saudi Arabia: ZATCA Phase 2

Saudi Arabia’s ZATCA programme is one of the most demanding e-invoicing regimes and a good benchmark for any vendor. Each company is onboarded with its own cryptographic identity, standard (B2B) invoices are cleared before issue, simplified (B2C) invoices are reported within a deadline, and invoices are bilingual with a QR code. If you operate in the Kingdom, see the [Saudi Arabia country pack](https://transferarc.com/saudi-arabia).

Request a demo: https://transferarc.com/contact


## Questions to ask any vendor

1. Is e-invoicing built into the platform, or a third-party add-on you must integrate and pay for separately?
2. Does it support both clearance and reporting, with automatic retries?
3. Are credit and debit notes generated from cancellations, amendments and no-shows automatically?
4. Does each company get its own onboarding and certificate?
5. Is the invoice produced from the booking, and does it post to the ledger in the same transaction?
6. Is the VAT/GST return compared with the ledger before filing?
7. How are invoices archived, and for how long?

For the bigger picture on choosing a platform, read [the complete guide to transfer management software](https://transferarc.com/blog/transfer-management-software).


## Frequently asked questions.

### What is e-invoicing?

E-invoicing means issuing invoices as structured data files, usually XML, that tax authority systems can read automatically. Depending on the country, invoices are either cleared by the tax authority before issue or reported to it within a deadline.

### What is the difference between clearance and reporting?

With clearance, the tax authority must approve the invoice before it is issued to the customer, which is common for B2B invoices. With reporting, the invoice is issued first and reported within a deadline, which is common for B2C invoices.

### Does TransferArc support e-invoicing?

Yes. E-invoicing is built in-house: invoices, credit notes and debit notes are produced as UBL 2.1 XML with a hash chain, signature and QR code, cleared or reported to the tax authority where required, and archived as bilingual PDF/A-3 with the XML embedded.

### Is TransferArc compliant with ZATCA Phase 2?

Yes. ZATCA Phase 2 is built in-house, with per-company onboarding, clearance of standard invoices and reporting of simplified invoices with retries.