XAdES is not VeriFactu: two systems people keep confusing
"If I sign my FacturaE with XAdES, do I comply with VeriFactu?" No. They are two separate compliance systems that happen to share a common input (a signing certificate) but solve completely different problems for different audiences.
The confusion in one sentence
"We use XAdES to sign our invoices, so we're covered for VeriFactu, right?" This question, or a variation of it, comes up repeatedly in ERP product planning conversations. The answer is no, and understanding why requires separating two distinct concepts that Spanish fiscal regulation has layered on top of each other.
Both systems involve signing XML with a certificate. That's where the similarity ends. The format, the purpose, the destination, and the legal obligation are completely different.
What FacturaE + XAdES is
FacturaE (format version 3.2.2) is Spain's mandatory electronic invoice format for business-to-government (B2G) transactions. Any invoice issued to a Spanish public administration (central government, regional government, local council) must be delivered as a FacturaE XML document. The obligation has been in force since 2015 for central government and has progressively expanded.
The signature format for FacturaE is XAdES-EPES (XML Advanced Electronic Signatures with Explicit Policy). XAdES is an ETSI standard that extends basic XMLDSig with long-term validity properties: it embeds the signing policy, the certificate chain, and in higher profile variants, a trusted timestamp and OCSP responses. The signature is a document-level signature: it attests to the content of the invoice document.
After signing, the FacturaE document is submitted to FACe (Punto General de Entrada de Facturas Electrónicas), the Spanish government's centralized e-invoice portal. FACe validates the XSD schema and the XAdES signature before routing the invoice to the recipient public entity.
What VeriFactu is
VeriFactu (Royal Decree 1007/2023) is a completely separate system. Its purpose is not to deliver an invoice to a recipient; it's to register every invoice your software issues with AEAT (Spain's tax authority) in real time, regardless of who the recipient is.
VeriFactu is planned to become mandatory in October 2028 (announced by the Ministry of Finance; pending regulatory approval). It applies to all invoices, not just public sector ones.
The signature format for VeriFactu is XMLDSig, the base XML signature standard, without XAdES extensions. The VeriFactu XML payload is simpler than FacturaE: it contains key fields from the invoice (NIF, series, date, type, amounts) plus a SHA-256 hash chain linking each record to the previous one. This chain is what makes the records tamper-evident.
Submission is via mutual TLS (mTLS) over HTTPS to AEAT's web service endpoint, using the issuer's certificate for both the XMLDSig signature and the TLS client authentication. AEAT acknowledges the submission in real time.
Side-by-side comparison
| FacturaE + XAdES | VeriFactu | |
|---|---|---|
| Purpose | Deliver an e-invoice to a recipient | Report invoice issuance to AEAT in real time |
| Recipients | Spanish public administrations (B2G) | AEAT (tax authority) |
| XML format | FacturaE 3.2.2 (full invoice) | VeriFactu registro (key fields only) |
| Signature | XAdES-EPES (extended, long-term validity) | XMLDSig (base standard) |
| Transport | HTTPS POST to FACe API | mTLS to AEAT SOAP endpoint |
| Hash chain | No | Yes: SHA-256 linking each record to the previous |
| Invoices covered | Only B2G invoices | All invoices issued (B2B, B2C, B2G) |
| Obligation since | 2015 (central gov), expanding | Oct 2028 (planned, pending approval) |
| Certificate | Issuer's certificate (XAdES-EPES) | Issuer's certificate (XMLDSig + mTLS) |
What they have in common
Both systems require a certificate from the invoice issuer, specifically the empresa certificate issued by FNMT or an accredited CA. That's where the confusion starts: same certificate, two completely different uses.
In Kreyo's component model, a client uploads their certificate once and it covers both products. Kreyo FacturaE uses it for XAdES-EPES signing and FACe submission; Kreyo VeriFactu uses it for XMLDSig signing and mTLS authentication with AEAT. The certificate is the common thread; everything else is separate.
What happens if you only implement one
If you only implement FacturaE + XAdES, your software can deliver invoices to public sector clients. But you're not reporting to AEAT in real time. Once VeriFactu is mandatory, every invoice you issue without a VeriFactu registration is a compliance gap, regardless of whether it went to the public sector or not.
If you only implement VeriFactu, your invoices are registered with AEAT in real time. But if your clients invoice public administrations, those invoices still need to be delivered as FacturaE XML to FACe. VeriFactu registration doesn't replace the delivery mechanism.
Most ERPs serving the Spanish market need both. A client invoicing a town hall must simultaneously submit a FacturaE to FACe and register a VeriFactu record with AEAT.
How Kreyo separates them
Kreyo has two distinct products for the two distinct systems:
- Kreyo FacturaE: generates and signs FacturaE 3.2.2 XML with XAdES-EPES using your client's certificate, validates against the official XSD, and submits to FACe.
- Kreyo VeriFactu: builds and signs VeriFactu records with XMLDSig, manages the SHA-256 hash chain, and submits to AEAT via mTLS using your client's certificate.
Separate pricing, separate API endpoints, separate documentation, but the same certificate upload, the same API key, and the same JSON invoice model as input. If a client invoice goes to a public administration, you call both.