VeriFactu for ERP integrators: Sage, Odoo, a3 and custom systems
Assessing a client base means distinguishing versions, customisations and responsibilities. This guide proposes questions to resolve; it does not describe client incidents or substantiate Kenea connectors. Part of the VeriFactu for integrators guide.
Editorial review: .
What to check with each vendor
This table organises the review; it is not a compatibility catalogue. Confirm product, version, edition and module with the vendor and retain the documentation before deciding.
| Source | General adaptation approach | What to check |
|---|---|---|
| Sage | Confirm the update and scope for the specific product | Supported version, available functionality and third-party additions |
| Odoo | Identify edition, hosting, module and author | Distinguish official from third-party modules; review maintenance and own invoicing-related modules |
| a3 (Wolters Kluwer) | Check the specific application in the suite | Which application issues and which receives invoices; adviser–client workflow when clients invoice elsewhere |
| Custom system | Inventory components and owners | Applicable mode requirements, data, tests and declaration of responsibility |
If the module covers the installation and is maintained, evaluate it first. Compare cost, responsibility and feasibility for the particular case; no option is universally cheapest.
What to check in customisations
A customisation may change the expected flow, but does not automatically mean the module fails. Suggested review and test scenarios include:
- Invoicing elsewhere. Check issuance points in projects, point-of-sale, web and batch processes.
- Custom series and numbering. Numbering by branch, client or a non-calendar financial year. Records need series and numbers consistent with the hash chain.
- Manual corrections. Installations where “correcting” means editing the original invoice. VeriFactu requires a creation record for the corrective invoice and, where appropriate, a cancellation record; never a silent edit.
- Batch invoicing. Test coordination of concurrency and chaining; parallel execution alone does not prove a defect.
- PDF as the source of truth. Installations where the correct data is in the PDF and the database lags behind. The record must originate at issuance, not from the document.
- Older versions. Confirm supported options and the cost of updating customisations.
The technical assessment determines whether updating and configuring is enough or additional development is needed. The fictional sample report shows how to document that decision.
Operating across dozens of clients
Adapting one ERP installation is one project. Adapting forty installations and operating them afterwards is a different scale of work, with substantial consequences for an integrator’s year.
| Problem | What is needed |
|---|---|
| Each client is a different issuer | Separate hash chains per issuer. A client identifier accompanying each record |
| Retries | Stable operation identity and a service-appropriate reconciliation procedure. See states and retries |
| Visibility | A shared view of submitted, pending, rejected and inactive clients. A client that stops submitting may not call |
| Certificates | An expiry inventory per client and advance reminders, for example two months ahead |
| Onboarding and departure | Procedures for adding clients and closing out departing clients’ chains, including export of their records |
| Evidence | A monthly client report available if requested |
This table describes the needs of a multi-client operation, rather than a list of included features. KeneaFactu is an operational product: request a demonstration to check what it covers for your case and which integrations or additional work are needed.
Certificates and representation
Distinguish service authentication from record signing and check the mechanisms allowed for the case. Resolve two issues before integrating:
- Identity and representation. Possession of a certificate does not automatically authorise acting for any client.
- Unmanaged certificate custody. Avoid .p12 files in email, passwords in spreadsheets and unclear expiry ownership.
Decide who holds each client’s certificate, where it is kept, who renews it and how far ahead. Where representation is involved, formalise it in writing. Changing this after forty clients reach production is difficult.
Assessment checklist for each source
Before choosing an ERP adaptation route, answer these questions for every source you maintain:
- Which versions and editions do clients use? How many different versions are present?
- Does the vendor offer a VeriFactu module for that version? Has it confirmed this in writing?
- How many issuance points exist in the installation? Do they all use the standard flow?
- Which series, corrective invoices, cancellations and simplified invoices does each client use?
- Who produces the application? Where is its declaration of responsibility, and does it cover the customisation?
- Which clients fall under SII or foral rules and outside the applicable obligation?
- Who holds each certificate, and when does it expire?
- How will you know tomorrow that one client has stopped submitting?
- Can you test all this in the AEAT test environment before changing production?
- Which date applies to each client? See the VeriFactu 2027 deadlines.
When an integration layer makes sense
| Worth considering | May be unnecessary or unsuitable |
|---|---|
| You maintain many clients on one source and want a consistent approach | You have three clients on a supported version and the vendor module covers them |
| The official module does not cover customisations, series or issuance points | The installation is standard and an update is feasible |
| You need one control view across clients, with alerts and evidence | The vendor already supplies the multi-client dashboard needed |
| Your custom system issues invoices and you do not want to build and maintain error, duplicate and state handling | You have a development team, few source systems and prefer to integrate a tax API yourself |
| The source permits integration at the point of issuance | The source only produces PDFs and issuance cannot be intercepted; changing software may be necessary |
Connector reuse is an objective to prove for each version, configuration and customisation. Kenea has no universal connector. The assessment may recommend a different route; later development requires a quotation and scope acceptance. See services.
Sources
- Royal Decree 1007/2023, invoicing software systems regulation.
- Order HAC/1177/2024, technical specifications.
- AEAT: invoicing software systems, FAQs and test environment.
Discuss an assessment of my software
This guide is general technical information, not tax or legal advice. References to Sage, Odoo and a3 are descriptive; trademarks belong to their owners and Kenea is not affiliated with them. Discuss your case with your adviser.