An invoice can be perfectly valid and still be financially useless if nobody can answer two questions: Was it accepted? and When was it actually paid? Spain's new B2B e-invoicing framework is designed to make those answers machine-readable. For businesses, that means the project is not just about replacing PDF attachments with structured files. It is also about connecting sales invoices, accounts payable, bank activity, and payment evidence into one reliable workflow.
The framework was published in 2026, but many businesses do not have a fixed calendar date yet. The implementation clock begins when the ministerial order that develops the public e-invoicing solution takes effect. From that trigger, businesses whose prior-year turnover exceeded €8 million have 12 months, while the rest have 24 months. That lead time is useful if you treat it as an accounting and operations project rather than a last-minute software purchase.
This guide explains what the rule changes, how to determine which deadline applies, and how to build a payment-status workflow that will hold up when invoices move between different platforms.
What Spain's new framework actually requires
The framework applies to businesses and professionals that are already required to issue invoices when the customer is another business or professional with its economic headquarters, permanent establishment, domicile, or habitual residence in Spain, and the transaction is addressed to that Spanish location.
The obligation is broader than “send the customer an electronic copy.” The invoice must be a structured electronic message that can be processed by software. The permitted syntaxes include:
- CII
- UBL
- EDIFACT
- Facturae
The data model must follow the EN 16931 semantic model, with the adaptations specified by Spanish rules. Every invoice also needs a unique identifier that includes the issuer's tax identification number, the invoice number and series, and the issue date.
The system has two connected layers:
- Private exchange platforms that route invoices between issuers and recipients.
- A public e-invoicing solution developed and managed by the Spanish Tax Agency, which acts as a universal repository and provides payment-tracking services.
A business may use a private platform, the public solution, or a combination. If it has not agreed with suppliers on a private platform for receiving invoices, the public solution is the default. If it does choose a private receiving point, it must make that point known in its business communications and, where applicable, on its website.
This is why a standalone invoicing screen is unlikely to be enough. The system has to identify the counterparty correctly, produce an accepted structured format, route the document, preserve its identity, and record the invoice's later states.
Which deadline applies to your business?
The decree's formal entry into force is separate from its effective application. Its operational requirements are deferred until the ministerial order for the public solution takes effect. After that order's effective date:
- Businesses and professionals whose prior calendar-year volume of operations exceeded €8 million enter the framework after 12 months.
- Other businesses and professionals enter it after 24 months.
Do not calculate your deadline by adding a year or two to the date the decree appeared in the Official State Gazette. The relevant trigger is the implementing order, and the turnover test uses the immediately preceding calendar year. A business that grows past the threshold should therefore keep an annual record of the figure used in its assessment, not rely on an informal estimate.
There is also a transitional legibility rule. During the 12 months after the framework becomes effective for a business above the €8 million threshold, that business must generally accompany its electronic invoices with a PDF that ensures the recipient can read them, unless the recipient expressly agrees to receive the original format. That PDF is a bridge for usability; it is not a substitute for the structured invoice.
The decree also gives smaller businesses a further transition for reporting invoice states. For individuals and certain income-attribution entities at or below the €8 million level, the state-reporting provisions become mandatory after 12 months from the date the decree produces effects for the relevant group. Because these transitions interact, document the trigger dates and your entity type with your Spanish tax adviser.
The payment-status obligation is the operational centerpiece
The most important change for day-to-day finance teams is that invoice status becomes a defined data stream.
The recipient must communicate at least:
- Commercial acceptance or rejection, with the date.
- Full effective payment, with the effective payment date.
The recipient may also communicate partial acceptance or rejection, partial payment and amount, and assignment of the invoice to a third party for collection or payment. Those extra statuses can be valuable for credit control, but they do not replace the mandatory full-payment event.
Status information generally must be sent within four natural days of the event, excluding Saturdays, Sundays, and national holidays. For the public solution, a recipient must report the full effective payment of each received invoice that was not rejected, together with the payment date, regardless of whether the invoice traveled through a private platform. The recipient must also report the payment due date.
That creates a short control window. A bank reconciliation performed weeks after month-end may be good enough for management reporting, but it is too slow to be the only mechanism that tells the invoicing system a payment happened. Your accounts-payable process needs an event or queue that notices the bank settlement, matches it to the invoice, and sends the required status on time.
Define “paid” carefully
The effective payment date is not necessarily the date someone clicks “paid” in an accounting application. It is tied to the supplier actually receiving the money. For a transfer, that generally means the date the payer's account is debited. For a cash payment, it is the cash-payment date. For an agreed compensation of obligations, it is the date of that compensation.
Making an invoice available for factoring or another early-collection mechanism does not by itself make it paid. The relevant date is when the supplier actually receives the funds. That distinction matters when your business uses factoring, supply-chain finance, card settlement, or an intermediary that reports a payment before the underlying cash reaches the supplier.
Build these definitions into your matching rules. At minimum, retain:
- Invoice identifier and supplier tax ID
- Issue date, service or delivery date, and receipt date
- Contractual and calculated due dates
- Acceptance or rejection status and timestamp
- Payment amount, bank transaction ID, and actual settlement date
- Full, partial, disputed, assigned, and reversed-payment indicators
- The platform or channel used to transmit each event
When a payment is reversed or misapplied, do not silently overwrite the original event. Preserve the original transaction, record the correction, and route the invoice to review. An audit trail is more useful than a green “paid” label that no longer explains what happened.
Connect the rule to Spain's payment-term rules
Electronic reporting does not create a new excuse to delay payment. Spain's commercial late-payment rules generally set a 60-day payment limit between businesses, with specific rules for when the clock starts and how acceptance procedures work. Suppliers generally must deliver the invoice or equivalent payment request within 30 days of receiving the goods or services. Electronic receipt can start the payment-term calculation when the identity, authenticity, integrity, and receipt of the invoice are guaranteed.
The practical lesson is simple: store the dates that determine the payment clock, not just the date printed on the invoice. A purchase invoice with a missing service date, an unrecorded receipt date, or an undocumented acceptance step can make the due-date calculation difficult to defend.
For receivables, use the same discipline. Your sales ledger should show when the customer received the invoice, when it accepted or rejected it, and when funds settled. That gives a collections manager a reasoned next action instead of an aging report based only on issue dates.
A bookkeeping workflow that can meet the four-day window
You can prepare the process before choosing a platform. Start with a simple state machine for every invoice:
1. Create and validate
Generate the invoice from an approved customer record. Validate the tax IDs, required invoice fields, unique identifier, line amounts, tax treatment, currency, and due-date inputs before transmission. Rejecting malformed documents at creation is cheaper than resolving a platform rejection after the customer has already received an incomplete record.
2. Transmit and capture proof
Send through the chosen private platform or public solution. Store the transmission response, destination, timestamp, and the exact structured document or a content hash. If the platform transforms CII, UBL, EDIFACT, or Facturae messages, retain the original and the transformed representation or a reliable link between them.
3. Record acceptance or rejection
Route the recipient's commercial response into the invoice ledger. A rejection should create a reason code and an owner, not merely a red icon. If a correction is needed, issue a traceable rectifying invoice and preserve the relationship to the original.
4. Match settlement to the invoice
Import bank transactions frequently enough to meet the reporting window. Match by invoice identifier, counterparty, amount, and remittance information, with a review queue for partial payments, batch payments, fees, and currency differences. The person or process approving the match should be visible in the audit trail.
5. Report the payment event
When the invoice is fully settled, capture the actual effective payment date and send the required event within four qualifying days. Do not use the reconciliation date if it differs from the settlement date. If a platform is authorized to report on your behalf, retain the authorization and the delivery result.
6. Reconcile the books and the status ledger
At period-end, compare the invoice register, platform messages, bank activity, accounts receivable or payable balances, and the reported statuses. Investigate invoices that are marked paid in one system but remain open in another. This reconciliation is also where you catch duplicate invoices, missing credit notes, and payments posted to the wrong entity.
Common mistakes to avoid
Treating a PDF as the electronic invoice
A PDF may be readable, but it is not automatically a structured invoice. Keep any transitional PDF as a presentation aid while making the compliant structured message the authoritative record.
Assuming a private platform removes public reporting
Private platforms must participate in the Spanish system and interconnect with other platforms. More importantly for recipients, the full payment must still be communicated to the public solution under the decree, even when a private platform handled the exchange.
Using issue date as every other date
Issue date, delivery or service date, receipt date, acceptance date, due date, settlement date, and reporting date answer different questions. Collapsing them into one “invoice date” field destroys the evidence your payment workflow needs.
Reporting “paid” when money has only been arranged
Factoring availability, a scheduled transfer, or an internal approval is not necessarily effective payment. Wait for the event that represents the supplier receiving funds, then record that date.
Leaving platform ownership unclear
Decide who monitors failed transmissions, rejected invoices, unreported payments, and unmatched bank items. A platform can automate transport; it cannot decide who owns an exception unless you define that responsibility.
A practical readiness checklist
Before your effective deadline, confirm that you can answer “yes” to each question:
- Can we determine whether each customer and supplier falls within the Spanish B2B scope?
- Do we know whether our turnover puts us in the 12-month or 24-month phase?
- Can our invoicing system create a structured EN 16931-compatible message in an accepted syntax?
- Is our receiving endpoint public and tested with major counterparties?
- Can we preserve the original invoice and every transformed or transmitted version?
- Do we capture acceptance, rejection, due date, partial payment, and full payment separately?
- Can bank settlement data reach the invoice register within four qualifying days?
- Are payment reversals, credit notes, and disputed invoices routed to a human review queue?
- Can we reconcile platform statuses to the general ledger and bank statement?
- Do we have a documented owner for failures and evidence retention?
If any answer is “not yet,” start there. A small business can often make meaningful progress with a clean invoice register, disciplined bank imports, and explicit exception queues before it adopts a larger platform.
Simplify Your Financial Management
Spain's e-invoicing transition makes trustworthy records more valuable: you need to connect what was invoiced, accepted, due, paid, and reported. Beancount.io offers plain-text accounting that is transparent, version-controlled, and AI-ready, so your financial history stays inspectable as your invoicing workflow grows. Explore the docs or visualize reconciliations with Fava.