Four Days to Report: Spain's Invoice Status Obligation (Acceptance, Rejection, Payment)
Spain's B2B e-invoicing decree adds something no other European model has: both parties must report invoice status within four days, including the payment date. Late payment stops being a private dispute. Here is the workflow.
Four Days to Report: Spain's Invoice Status Obligation (Acceptance, Rejection, Payment)
Royal Decree 238/2026 does more than mandate a structured invoice format. It attaches a reporting obligation to the commercial life of every B2B invoice. Both the issuer and the recipient must report status changes to the exchange system within a maximum of 4 calendar days. The invoice stops being a static document and becomes a tracked lifecycle.
The Three Statuses
| Status | Who reports | What it means |
|---|---|---|
| Acceptance | Recipient | The invoice is formally and commercially accepted |
| Rejection | Recipient | The invoice is disputed, with grounds |
| Effective payment | Both parties' flows | The invoice has been paid, with the actual payment date |
The payment status is the sharp edge. Reporting includes the date the payment was effectively made. Combined with the invoice's stated payment terms, this produces exactly the dataset Spain's late-payment policy needs: which invoices were paid late, by whom, by how many days.
Why Spain Built This
The Crea y Crece Law's article 12 exists to fight commercial late payment. Spain's average payment delay runs around 80 days against a 60-day legal maximum under the late-payment framework. Until now, enforcement relied on litigation and self-reporting. Once payment dates flow into the exchange system by law, late payment becomes visible data rather than a private dispute between creditor and debtor.
For issuers, this is leverage: the debtor's payment behaviour is reported to a system the tax authority sees. For recipients, it is discipline: the "we never received a correct invoice" defence requires an actual rejection, reported within 4 days, with grounds.
The Workflow by Role
As the issuer
- Issue through your exchange channel (accredited private platform or the AEAT public solution).
- Monitor status. Acceptance, rejection, or silence. Silence past the reporting window is a signal to chase, in writing.
- Report payment when it lands. Your accounting or bank reconciliation flow marks the invoice paid; the status flows to the platform within 4 calendar days.
- Handle rejections as disputes. A rejection with grounds triggers your correction or credit-note process, not a resend of the same invoice.
As the recipient
- Triage on arrival. Accept or reject within the window. Build the 4-day deadline into your AP intake SLA, not your month-end.
- Reject with grounds. A rejection is a legal-status report. Grounds must be real: wrong amounts, missing purchase order, duplicate. Habitual rejection to delay payment is visible behaviour now.
- Report payment. Your payment run produces the effective payment date. The report follows within 4 calendar days.
- Reconcile exceptions. Invoices that sit in "no status" state are your compliance gap, not the system's.
Design Decisions for Your Stack
- Status is an event stream, not a document property. Model it as timestamped events (issued, delivered, accepted, rejected, paid) with the reporting deadline derived from each event.
- The 4-day clock runs on calendar days. Weekends and holidays count. An approval chain that parks invoices for a week cannot meet the deadline.
- Rejections need structured grounds. Free-text disputes slow everything. A coded reason set (amount mismatch, PO missing, duplicate, service not delivered) maps to your correction workflows.
- Payment reporting belongs in reconciliation. The moment a bank movement matches an invoice, the status event should be generated, not remembered.
- The AEAT copy flows regardless. Even on private platforms, the public solution receives the UBL copy. Status visibility is not optional infrastructure.
Interaction With Verifactu
The two obligations stack on the same invoice but do not overlap:
- Verifactu: your software registers the invoice immutably, hash-chained, with a QR code. Internal integrity.
- Crea y Crece status reporting: the invoice's commercial life is reported externally. Lifecycle traceability.
A compliant stack produces both from one issuance event: the SIF record for integrity, the exchange message for delivery, and the status events as the invoice moves toward payment.
Common Misreadings
"Status reporting starts when the mandate fully rolls out." It is part of the RD 238/2026 framework from each party's deadline. Design for it now; the workflow takes longer to build than the format.
"Only big companies report." The obligation binds both parties to a B2B invoice, scaled by the same turnover deadlines as the issuance duty.
"Rejection is a customer-service act." It is a reported legal status with a 4-day clock and grounds. Treat it as such.
"The payment date is private." Under this framework, it is reported data. That is the point of the law.
This material is information of a general nature and does not constitute legal or tax advice. For a specific situation, verify the current rules or consult a qualified adviser.