FacturaE 3.2.x: technical format, XAdES validation and what your AP team needs to know

FacturaE has been around for more than a decade, but most AP teams know it only by name. When a FacturaE invoice lands in the inbox, the usual practice is to open it in the viewer, read the presentation PDF and re-key the data. The XML ends up in the bin.

That is the mistake Crea y Crece will make very expensive. If the data is in structured XML and you work from the PDF, you are adding friction where the format was designed to remove it.

This article explains how FacturaE 3.2.x works technically, what differs from 3.2, what the XAdES signature does and how it impacts your accounts payable flow. No extra theory.

What FacturaE is and where it comes from

FacturaE is the official electronic invoice format of the Spanish Administration. The Ministry of Finance defines it and its technical documentation, including the XSD schema, is available at facturae.gob.es.

It was born mainly for B2G (business-to-government) invoicing. FACe (the State's Electronic Invoicing Platform) uses FacturaE as the mandatory format for suppliers invoicing the General State Administration. Since the Crea y Crece Law was approved, FacturaE is one of the two formats recognised for private B2B invoicing as well, alongside Peppol BIS 3.0.

The format is XML with its own schema. It is not standard UBL. It is not CII. It is the MINHAC (Ministry of Finance) schema. This has practical implications: a system that reads Peppol UBL does not read FacturaE without a specific field mapper. This information is general guidance. Consult your tax adviser.

FacturaE 3.2 vs FacturaE 3.2.x: what changed

The difference between 3.2 and 3.2.x is not trivial for AP. The most relevant changes are of two kinds: new fields and signature improvements.

Aspect	FacturaE 3.2	FacturaE 3.2.x
Electronic signature	XAdES-BES or basic XAdES-EPES	XAdES-EPES with updated signature policy
PO reference	Optional free-text field	Structured field with PO code
Line identification	Free text description per line	Article code + description separated
Additional dates	Only invoice date	Transaction date separate from issue date
VAT rates	Basic structure	Better support for intra-EU VAT and reverse charge
FACe	Compatible	Required for some entities

For AP, the most practical changes are the structured PO reference field and the separation between article code and description. Both make fuzzy matching against the PO easier: there is no need to infer the PO number from free-text on the line.

XML structure: what comes in a FacturaE invoice

A FacturaE file is an XML with three main blocks:

1. Header (FileHeader). Format version, number of invoices in the file (an XML may contain multiple invoices), mode (single or batch), currency scheme.
2. Parties (Parties). Issuer data (tax ID, legal name, address) and receiver data. Each field has its own tag: TaxIdentificationNumber, CorporateName, AddressInSpain.
3. Invoices (Invoices). One or several invoices. Each contains:
   • InvoiceHeader: number, series, type (full, abbreviated, summary), class (original, duplicate, corrective).
   • InvoiceDates: issue date, transaction date.
   • InvoiceTotals: taxable base, VAT amount, gross total, global discounts, total payable.
   • Items: line list. Each line has Description, Quantity, UnitPriceWithoutTax, TotalCost, DiscountsAndRebates, GrossAmount.
   • TaxesOutputs: VAT rates applied, base per rate, amount.
   • PaymentDetails: IBAN, due date, payment method.

What this means for AP: all the data you need for three-way matching is in tagged fields. UnitPriceWithoutTax is the pre-VAT unit price, which is the one you should compare with the PO price. Quantity is the billed quantity. TotalCost is the line amount before discounts.

XAdES: what it is and why it matters

XAdES (XML Advanced Electronic Signatures) is the European standard for advanced electronic signatures over XML documents. It is defined in ETSI EN 319 132 and is the mechanism FacturaE uses to guarantee the integrity and authenticity of the invoice.

There are several XAdES levels. FacturaE uses XAdES-EPES (Explicit Policy Electronic Signature), which includes an explicit reference to the applied signature policy. In practice this means the signature embeds:

• The signer's certificate (issuer's tax ID tied to the signature).
• The signature timestamp.
• A cryptographic reference to the signature policy published by the Ministry of Finance.
• The SHA-256 hash of the document content.

For AP, the practical consequence is twofold. First: you can verify that the XML content has not been modified since the issuer signed it. If the hash of the XML you receive matches the hash embedded in the signature, the document is intact. Second: the issuer's tax ID is cryptographically tied to the signature. You cannot impersonate an issuer without access to their certificate.

This is relevant for AP fraud detection. A FacturaE invoice with a valid XAdES signature from a known supplier's tax ID is harder to forge than a PDF sent by email.

FACe: the public e-invoice platform

FACe (the State's Single Entry Point for Electronic Invoices) is the public platform for receiving supplier invoices addressed to the Administration. If your company supplies public bodies, you already know FACe. If your company receives invoices from suppliers who also have public contracts, those suppliers may use FACe for all their issuance, including private B2B.

For the receiver in a private B2B context, FACe is not a mandatory platform. FacturaE invoices can arrive by email, through a supplier portal or via private intermediary platforms. FACe is the mandatory route only for invoices addressed to the Administration. This information is general guidance. Consult your tax adviser.

What is relevant for AP: if you receive an invoice generated from FACe, the XML comes with the standard FacturaE structure and an XAdES signature. Your AP system can process it exactly like any other FacturaE.

How to process FacturaE in your AP flow

The correct flow for a received FacturaE invoice has four steps:

1. Receipt and format identification. The file has extension .xsig or .xml. The AP system must detect that it is FacturaE by reading the XML namespace (http://www.facturae.es/Facturae/2009/v3.2/Facturae for 3.2, with variant for 3.2.x).
2. XAdES signature validation. Verify that the content hash matches the one embedded in the signature and that the certificate is valid. This can be done with standard libraries or delegated to an intermediary platform.
3. Tag-based field extraction. Read UnitPriceWithoutTax, Quantity, TaxIdentificationNumber and the PO reference field. No OCR. No pixel interpretation.
4. Three-way matching. Compare the extracted fields with the PO and delivery note. With clean data, matching accuracy rises significantly.

The critical point is step 3. If your AP system has no FacturaE parser, steps 2 and 4 also fail. The parser must know the FacturaE 3.2.x XSD schema to map fields correctly.

AP-accepted formats: reference table

Format	Type	Signature	Required parser	Typical use
FacturaE 3.2.x	XML MINHAC XSD	XAdES-EPES	Specific FacturaE parser	B2G and B2B ES
Peppol BIS 3.0	XML UBL 2.1	Peppol signature (4-corner network)	UBL/EN16931 parser	Cross-border B2B EU
Signed PDF/A	PDF + digital signature	PAdES or XAdES	OCR + PDF extractor	Not valid under Crea y Crece as main format
Unsigned PDF	PDF	None	OCR	Transition period, suppliers not yet adapted

Common errors processing FacturaE

Four problems that come up again and again in AP teams starting to process FacturaE:

Problem 1: using the presentation PDF instead of the XML. Many FacturaE invoices are sent with a presentation PDF attached. The PDF is for the human reader to understand the invoice. The XML is the official data source. Processing the PDF with OCR and discarding the XML wastes the format.

Problem 2: not validating the XAdES signature. If your system extracts data from the XML without verifying the signature, you cannot know whether the document was modified in transit. For high-value invoices, this is a significant fraud risk.

Problem 3: confusing unit price with line total. UnitPriceWithoutTax is the pre-VAT unit price. TotalCost is the total line amount before discounts. For three-way matching, you must compare the invoice's unit price with the PO's unit price, not totals. The line total depends on quantity and can mask price discrepancies.

Problem 4: ignoring corrective invoices. FacturaE has an InvoiceClass field that can be OO (original), OR (corrective by replacement) or OC (corrective by difference). If you receive a corrective and your system treats it as an original, you will duplicate or confuse amounts in the received-invoices ledger.

Case: advisory firm managing AP for 8 clients

An advisory firm in Tarragona manages accounts payable for eight industrial SMEs. In total, they process around 240 invoices per month across all clients. Before adapting the flow, the process was: download PDF from each client's email, re-key it into each client's ERP, verify by hand.

When three of their main suppliers started issuing FacturaE voluntarily, the advisory continued to process the attached PDF out of habit. Result: in one quarter, four divergences were detected between the XML amounts and the manually keyed amounts. Two were capture errors without consequences. One was a line discount the human ignored when copying. The fourth was a corrective invoice that entered as an original and doubled the amount in the VAT ledger.

Correcting the fourth error took four hours of work and a supplementary tax return. The cost of the error exceeded several months of having a correct FacturaE parser.

Frequently asked questions

Is FacturaE 3.2.x mandatory, or is 3.2 enough?

FACe requires 3.2.x for some public entities. For private B2B under Crea y Crece, the implementing regulation specifies valid formats. Check the updated documentation at facturae.gob.es and with your adviser. [Consult your tax adviser]

How do I validate that an XAdES signature is correct?

There are open-source libraries (Java, .NET, Python) that validate XAdES-EPES. You can also use the FACe validator or intermediary platforms that do it automatically in the ingestion flow.

Is a PDF emailed with a digital signature FacturaE?

No. FacturaE is the XML format with the Finance Ministry XSD schema. A digitally signed PDF is a PDF with a signature, not FacturaE even if it includes an electronic signature.

Can there be multiple invoices in a single FacturaE file?

Yes. The format allows several invoices in one XML file. The BatchIdentifier field in the header identifies the batch. Your AP system must iterate over the Invoices block to process each invoice in the batch.

How do I handle a corrective invoice in AP?

Read the InvoiceClass field. If it is OR or OC, it is a corrective. You must identify the original invoice it corrects (ReasonDescription field and reference to the original invoice) and apply the corresponding adjustment in the received-invoices ledger. Do not treat it as a new invoice.

Does FacturaE work for intra-EU invoices?

Yes, the format has specific fields for intra-EU VAT and reverse charge. For European suppliers, however, you are more likely to receive Peppol BIS 3.0. [Consult your tax adviser]

What your AP team needs to know

FacturaE 3.2.x is the XML format with XAdES signature that will land in your inbox as your suppliers adopt Crea y Crece. Three concrete things:

1. The XML is the official data source. The attached PDF is for visualisation. Your AP system must read the XML, not the PDF.
2. The XAdES signature guarantees the data has not been altered. Validating it is a security layer against fraudulent invoices.
3. Corrective invoices have their own class (InvoiceClass). A parser that does not distinguish them from originals generates errors in the VAT ledger.

This information is general guidance. Consult your tax adviser.

Related content

• Three-way matching: cross-checking invoice, PO and delivery note line by line
• Crea y Crece Law: mandatory B2B e-invoicing and AP automation