What Is a Receipt with XML? The Fallback Document for E-Invoicing Gaps

EU e-invoicing mandates are rolling out across member states with a clear directive: every business-to-business transaction needs a structured, machine-readable document. But corporate travel consistently breaks the assumption that every supplier can comply. Hotels booked through aggregators, small properties without e-invoicing infrastructure, and suppliers in countries still phasing in their mandates all create gaps where no proper e-invoice arrives. The question for finance teams isn't whether those gaps will exist. It's what happens to the booking when they do. This article explains exactly what a Receipt with XML is, which finance rights it carries (and which it doesn't), how the format varies by country, and where Navan positions it within its document hierarchy. For a broader overview of travel expense documentation requirements across finance teams, Navan's documentation guide covers the full landscape.

What is a Receipt with XML?

A Receipt with XML is a PDF receipt with an embedded machine-readable XML payload, formatted to match the local e-invoicing mandate. The XML follows the structured format that the relevant country requires:

• Factur-X in France
• ZUGFeRD (Cross-Industry Invoice/CII XML) in Germany
• UBL (Universal Business Language) for Peppol-based markets like Belgium and the Nordics

The "with XML" distinction matters because it separates this document from an ordinary paper or PDF receipt. A standard receipt is human-readable but not machine-readable in any structured way. A Receipt with XML contains structured data that a company's enterprise resource planning (ERP) system can parse and import directly, regardless of which country's format standard applies.

1    <rsm:ExchangedDocument>
2        <ram:ID>E-10000001234</ram:ID>
3        <ram:TypeCode>751</ram:TypeCode>
4        <ram:IssueDateTime>
5            <udt:DateTimeString format="102">20260706</udt:DateTimeString>
6        </ram:IssueDateTime>
7        <ram:IncludedNote>
8            <ram:Content>Train receipt</ram:Content>
9        </ram:IncludedNote>
10        <ram:IncludedNote>
11            <ram:Content>Booking ID: WXR-7K2-QP5</ram:Content>
12        </ram:IncludedNote>
13        <ram:IncludedNote>
14            <ram:Content>SNCF TGV INOUI 6172 (executive) - Paris Gare de Lyon 2026-07-10 10:38 -> Marseille St-Charles 2026-07-10 13:59</ram:Content>
15        </ram:IncludedNote>
16        <ram:IncludedNote>
17            <ram:Content>Trip Name: Marseille Client Visit</ram:Content>
18        </ram:IncludedNote>
19        <ram:IncludedNote>
20            <ram:Content>Trip purpose: Client meeting</ram:Content>
21        </ram:IncludedNote>
22    </rsm:ExchangedDocument>

Above: Example snippet from embedded XML payload (Factur‑X, France)

Why it's labeled as a receipt, not a tax invoice

The document is deliberately labeled as a receipt, not a tax invoice or e-invoice. That distinction isn't semantic: it defines which finance rights the document carries. A tax invoice meets the full requirements of the local e-invoicing mandate, including the seller's VAT registration, the buyer's VAT number, and a detailed tax breakdown. A Receipt with XML doesn't meet those full requirements because the supplier either couldn't or didn't provide the data necessary for tax invoice status.

Navan makes this labeling explicit because honesty about a document's status protects the company at audit. Presenting a receipt as a tax invoice would create compliance risk. Presenting a structured receipt that accurately describes what it is, and what finance rights it supports, provides a defensible position.[1]

Which finance rights does a Receipt with XML carry?

The distinction between what a Receipt with XML preserves and what it doesn't is the most critical thing finance teams need to understand. The answer depends on which type of tax benefit is at stake.

Corporate income tax (CIT) deduction: yes

A Receipt with XML is sufficient supporting documentation for the corporate income tax deduction on travel spend. The document proves that the expense was incurred, provides a structured record of the transaction, and creates an audit trail that tax authorities can verify.

A Big 4 accounting firm reviewed Navan's Receipt with XML position in a formal memorandum and confirmed this: a structured receipt of this form meets the documentation requirements for CIT deduction. The memorandum draws the same boundary the document itself does: valid for CIT deduction, not a substitute for a tax invoice when VAT reclaim is at stake.[2]

VAT reclaim: requires a supplier tax invoice

A Receipt with XML on its own does not carry VAT reclaim rights. Recovering input VAT on travel expenses still requires a proper tax invoice from the supplier, including the seller's VAT registration number, the buyer's VAT number, and a line-item tax breakdown. Navan's Tier 1 and Tier 2 documents (where Navan issues or collects the supplier invoice) are what enable VAT reclaim; the Receipt with XML is the structured fallback when that invoice genuinely isn't available.

In other words, Navan maximizes VAT reclaim wherever a supplier invoice exists and uses the Receipt with XML to preserve all remaining finance rights when it doesn't. For a deeper look at why reclaiming VAT is so challenging in corporate travel, Navan's VAT guide covers the full process.

This is the distinction that finance teams most frequently misunderstand. Losing VAT reclaim on a booking doesn't mean losing all tax benefit. The CIT deduction, which reduces the company's taxable income by the amount of the expense, remains intact.

Quick reference: document types and finance rights

**VAT reclaim still possible for the same booking if a supplier tax invoice is available via Tier 1 or Tier 2.

When does Navan issue a Receipt with XML instead of a tax invoice?

Navan always issues the best document legally available for every booking. The Receipt with XML enters the picture only when neither of the two higher-tier options is possible.

Navan's 4-Tier Document Cascade

Navan's document hierarchy works as a cascade: each booking progresses through the tiers until it lands on the best document the supplier and the law permit.

• Tier 1: Navan issues the e-invoice on the supplier's behalf. This requires explicit supplier authorization. Example suppliers: Lufthansa Group, Deutsche Bahn, ÖBB. Full VAT reclaim and CIT deduction.
• Tier 2: Navan collects the supplier's own invoice. The supplier issues and sends the document directly or through a certified network. Full VAT reclaim and CIT deduction.
• Tier 3: Receipt with XML. Navan generates a structured receipt when no tax invoice can be collected. CIT deduction preserved. No VAT reclaim.
• Tier 4: Estimated charges (proforma). A temporary placeholder used when the final cost isn't yet known, such as a long-lead hotel booking before check-out. No finance rights until replaced by a higher-tier document.

Common scenarios that trigger Tier 3

Three situations typically result in a Receipt with XML rather than a tax invoice:

• Aggregator bookings: The flight or hotel was booked through an aggregator platform. The aggregator is the legal seller, and the supplier's tax invoice isn't available to the company.
• Small or non-compliant suppliers: The hotel, ground transport provider, or rail operator doesn't have the e-invoicing infrastructure to issue a structured invoice addressed to the company.
• Pre-mandate suppliers: The supplier operates in a country where e-invoicing mandates haven't yet taken effect, or where the specific travel category (e.g., certain rail services) is exempt from the mandate.

In each case, the Receipt with XML means the booking doesn't go undocumented. The company has a structured record, a CIT-defensible document, and a clean audit trail, even though the full tax invoice path wasn't available.[3]

How does the Receipt with XML format vary by country?

The format of the embedded XML isn't arbitrary. Navan matches the Receipt with XML to the local mandate's technical standard, so the company's ERP reads the structured data directly regardless of the originating country.

What the format alignment means for finance teams

Factur-X and ZUGFeRD are technically identical standards, differing only in name and in the filename of the embedded XML file (factur-x.xml vs. zugferd-invoice.xml).[4] The underlying schema is UN/CEFACT Cross-Industry Invoice (CII), which is compliant with the European standard EN 16931.

For Peppol-based markets, the XML uses UBL (Universal Business Language) syntax, which is the transmission standard for the Peppol four-corner network. Despite the syntax difference from CII, the semantic content aligns with EN 16931.

The practical result: a company receiving Receipts with XML from bookings across France, Germany, Belgium, and Poland gets structured data in each country's required format. The finance team doesn't need to handle different document types or build separate processing workflows. The ERP reads the embedded XML, extracts the transaction data, and posts it, regardless of which country's format standard applies.

How Navan's agent model protects your finance rights

The Receipt with XML doesn't exist in isolation. It's one component of a broader invoicing architecture that starts with how Navan structures every booking.

Navan operates as a disclosed agent (pass-through agent) for every transaction. The supplier invoices the company directly, and the company's VAT number appears on the invoice. Navan never becomes the legal seller or merchant of record. This agent model is structurally designed to preserve VAT reclaim rights whenever a supplier invoice is available (Tier 1 and Tier 2 of the cascade).[5]

This means Navan's default outcome for eligible bookings is full VAT reclaim via supplier e-invoices (Tier 1 and Tier 2); the Receipt with XML only comes into play where those invoices do not exist.

When VAT reclaim isn't possible because no supplier invoice exists, the Receipt with XML preserves every other finance right the law permits. The combination of the agent model (maximizing the bookings where VAT reclaim works) and the Receipt with XML (covering the gap where it doesn't) means every booking gets the best possible financial outcome.

For context on Navan's full agent model and how it compares to bill-back and merchant-of-record approaches, see TMC commercial models and VAT reclaim. For the complete document hierarchy, see understanding travel document types. Navan's travel expense reconciliation automation guide explains how structured documents like the Receipt with XML streamline month-end close.

Set realistic expectations with your tax team

The Receipt with XML closes a real gap in e-invoicing compliance for corporate travel. Finance teams that understand what this document does, and what it explicitly doesn't, can set appropriate expectations with auditors and tax advisors before month-end close. The CIT deduction is preserved. The audit trail is structured and machine-readable. VAT reclaim, where it requires a supplier tax invoice, follows a different path through Navan's Tier 1 and Tier 2 document flows.

For a broader view of how e-invoicing mandates affect corporate travel across the EU, see our complete guide to e-invoicing.