A Spanish business adapting billing software should decide where the official billing record is created and which component owns its integrity before purchasing an integration API. Compare an existing vendor upgrade, an intermediary service and custom implementation against the same business flow. A successful test request does not define the responsibilities of the complete billing system.
Timing matters because older proposals may carry superseded assumptions. As checked on 27 September 2026, AEAT's current FAQ identifies mandatory adaptation dates of 1 January 2027 for corporation-tax taxpayers and 1 July 2027 for the other obligated taxpayers described in the rules. Scope and exceptions still need confirmation for your entity by its responsible adviser. Do not apply one date to every Spanish organisation.
TuniCyberLabs serves buyers remotely. This guide addresses software design and procurement; the accountant or tax adviser should approve the applicable invoicing rules, mode and transition requirements.
Identify the system that actually issues the invoice
Consider a fictional Spanish subscription business. A customer portal collects an order, a payment provider handles payment and an internal application generates the invoice. The ERP later receives accounting information.
Draw those steps before evaluating connectors. Establish which event constitutes invoice issuance in the approved business process, which system assigns the invoice reference and which component produces the billing record. Payment confirmation and invoice issuance should not become interchangeable merely because they occur close together.
Ask the existing software vendor what its supported upgrade covers. Replacing a functioning system may create unnecessary migration work if a maintained extension already satisfies the approved requirements. Conversely, a generic connector may leave an important custom invoicing path untouched.
Distinguish the mode from the entire regulatory framework
AEAT explains that VERI*FACTU is one of the system modes within the broader billing-software requirements. Its general guidance distinguishes the framework from the mode that submits structured billing records as invoices are issued.
Have the responsible adviser and software owner agree the intended arrangement, then require the supplier to identify its precise role. Do not accept a broad “VERIFACTU compatible” label without a description of which records, interfaces and responsibilities it covers.
Keep other invoicing projects separate in the specification. If the business also needs customer invoice exchange, payment reconciliation or a particular customer format, list those requirements explicitly. The name of one regulatory programme does not scope every finance integration.
Put record integrity inside the design boundary
AEAT's hash guidance explains the relationship between a record's fingerprint and the chain of records used for traceability. Its technical information hub provides the implementation materials.
Use the current specification to determine where the relevant record is generated and retained. Ask how concurrent invoice creation, application restarts and failed downstream communication affect that process. These are engineering questions your supplier should answer for its chosen architecture.
Avoid duplicating authoritative record generation across several loosely connected services. If an intermediary owns part of the process, document the handoff and the evidence your application receives. The proposal should make that boundary reviewable without requiring the buyer to infer it from sample code.
Test the ordinary changes that expose hidden assumptions
Select examples from the organisation's real invoicing patterns, with sensitive information protected. Include the approved treatment of corrections and cancellations, multiple business entities where relevant and the identifiers needed to connect the record back to the source transaction.
Ask the team to demonstrate:
- ▸Two permitted invoice operations arriving close together.
- ▸A restart between the business event and downstream confirmation.
- ▸A repeated customer action that must not create an unintended duplicate.
- ▸A record rejected by the receiving service.
- ▸A permitted correction with the original history still understandable.
- ▸A credential problem that operations staff can distinguish from a data error.
Expected outcomes must come from the approved business rules and provider specification. Do not allow a developer to invent an accounting response simply to make an automated test pass.
Compare an intermediary with direct implementation
An intermediary can reduce the integration surface your team operates, but it also introduces a provider relationship and an interface to maintain. Ask which parts of validation, generation, submission and response interpretation it performs.
Request a demonstration of the information your organisation can retrieve if it changes provider. Identify recurring charges, supported environments, incident escalation and change notification. Review whether all your invoicing paths use the same arrangement.
For direct implementation, price specification review, testing, credential management and ongoing maintenance explicitly. Avoid treating a small number of endpoints as proof that the lifecycle will be inexpensive to operate. The business needs a maintained process, not only a working HTTP call.
Design a controlled transition from the existing software
Inventory every place invoices can currently be issued: the main application, an administrator tool, scheduled jobs or a secondary branch system. Include those paths in the transition decision so an overlooked screen does not continue using the old workflow.
Agree how historical records remain accessible and who approves the point at which the new process becomes authoritative. The responsible adviser should confirm any restrictions or obligations affecting retained systems. Engineering should implement the approved boundary and produce evidence that it works.
Rehearse with the receiving finance team. They should trace one business transaction through its invoice, billing record and relevant outcome, then investigate a deliberately incomplete example without relying on the original developer.
Buy a maintained billing capability
Request a mapping specification, responsibility diagram, test evidence, operational procedures and a named owner for provider changes. Establish how new invoice types or business entities enter the acceptance process after launch.
Use the CRM and ERP integration scope guide to organise dependencies and the software quote comparison worksheet to expose excluded work.
Explore software engineering services and request a Spanish billing-integration scope review. Bring the systems that issue invoices, the current vendor's proposal and the requirements your finance owner has approved.