abuenoben
Contact

Adapt your invoicing to VERI*FACTU

I review your current software, define the changes it needs and implement the technical adaptation. For businesses with their own software and agencies handling this work for a client.

Tell me how you invoiceSee my VERI*FACTU experience

Content reviewed

Who it is for
Businesses with their own software and agencies adapting a client’s system
First-hand experience
VERI*FACTU in my own business from my first invoice
First step
Review the system before agreeing scope, budget and schedule

Context

You do not need a technical specification to start. Tell me how you invoice, which tools are involved and what concerns you. If you use a commercial package, we first check what its provider offers and whether custom development is needed.

01

I use VERI*FACTU for my own invoicing

I built the software I use to manage my freelance business. I have used it with VERI*FACTU from my first invoice, with records accepted by AEAT in production.

The application brings together invoicing, payment tracking, expenses and exports for my accountant. That experience helps me account for the work that happens before and after an invoice is issued.

The linked case separates technical testing from real use. The software is an internal tool; its identity, access and business data remain private.

02

What we can address in your business

The solution depends on how you work today. These are situations where a custom adaptation may make sense.

01

Adapt your own software

Review the system you already use to invoice, identify what can stay and implement the changes needed for the agreed operating mode.

02

Connect invoicing to other systems

Define how orders or services reach invoicing and how their status returns to your tools, with the aim of avoiding duplicate records and manual steps.

03

Handle a client’s adaptation

For agencies, I can deliver the technical work under your brand. You keep the commercial relationship, with responsibilities and handover agreed in advance.

03

From review to delivery

I first review where invoices come from, which tools are involved and who maintains the software. Your adviser confirms applicability and operating mode; that gives us the basis for the technical work.

  • Initial review: what the provider can address, what needs development and what depends on third parties.
  • Proposal: scope, budget, schedule and acceptance criteria agreed before implementation.
  • Development and testing: issuing, responses, rejections and recovery in a separate environment.
  • Handover: operating and incident documentation, with technical support for the release’s responsible declaration.

04

VERI*FACTU API and implementation details

Scope is defined against published specifications, the product’s use cases and its real operating constraints.

01

Records and validation

Creation and cancellation records, XML/XSD, fiscal fields, chaining, fingerprint, QR and checks performed before submission.

02

Transport and certificates

Authentication, certificate custody, secure submission, idempotency, timeouts and strict separation between test and production.

03

Status and recovery

Acceptances, rejections, corrections, queues, controlled retries, reconciliation and traceability of every response.

05

Which date applies to your business

AEAT currently states 1 January 2027 for Corporate Income Tax taxpayers and 1 July 2027 for the other taxpayers covered by the relevant scope. Before treating either milestone as a project requirement, the client’s tax adviser should confirm the entity, territory, regime and exclusions.

The technical objective is to leave enough time to test a stable release, resolve rejections and rehearse operations rather than discover the real invoicing flow on the application date.

Validation standard

A useful test covers the complete lifecycle and retains per-version evidence. A single accepted submission does not prove that the system is operable.

  1. 01Creation and cancellation accepted in the external test environment.
  2. 02Reproducible rejection with the error surfaced without losing traceability.
  3. 03Correction linked to the previous record and accepted.
  4. 04Responsible declaration identified with the evaluated release.

Common questions

Short answers about scope, evidence and implementation boundaries.

Do I need custom development to adapt?+

Not always. If you use a commercial package, first check what its provider offers. Custom development makes sense for in-house software, connections between systems or needs that the provider’s update does not address.

Do I have to replace my invoicing software?+

That requires a review. I check whether it can be adapted, what access and documentation are available and what its provider allows. If adaptation is not viable, we clarify that before committing to development.

How much does adaptation cost and how long does it take?+

It depends on the software’s condition, invoice types, integrations and testing needed. After reviewing the case, I prepare a proposal with scope, budget and schedule. I do not promise a go-live date before understanding those dependencies.

What does a VERI*FACTU API integration include?+

Record modelling, XML validation, certificates, connection to AEAT services where applicable, responses, retries, traceability, testing and operating documentation. The exact scope depends on the operating mode and existing software.

Does AEAT approve or certify invoicing software?+

This service is not presented as an AEAT approval. The system producer issues a responsible declaration for each version and retains the evidence supporting that declaration.

Do VERI*FACTU and non-VERI*FACTU use the same flow?+

They share RRSIF requirements but are not the same operating mode. The decision affects submission, custody and other controls, so it needs to be fixed before architecture is finalised.

Can the flow be tested without customer invoices?+

Yes. The technical protocol should use controlled test identities and documents, isolate certificates and endpoints by environment, and avoid commercial data in validation artefacts.

Does the integration include tax advice?+

No. The work implements technical requirements and documents decisions. Applicability, tax treatment and fiscal acceptance remain with the client and its adviser.

Official sources

Spanish regulatory and technical sources used for this page. Specifications may change and must be checked again when a project starts.

Initial technical review

Tell me how you invoice and what needs to change.

Tell me which software you use, whether it is in-house or supplied by a provider, and what concerns you about the adaptation. If you are enquiring for an agency client, explain your role too. No technical diagram needed.

  • Do not send certificates, tax IDs, invoices or secrets through this form.
  • Tax and legal applicability must be validated with your adviser.
  • A human reply, normally within one business day.

Tell me what you need

Name, email and context. Budget, timing and format can be added if you already know them.

What context are you writing from?
A few lines about the project are enough.
Add more informationCompany, budget and timing, if you know them.
Data used and how to withdraw consent

I agree that Google Ads may measure this enquiry using its submission ID, date, my normalized email address transformed with SHA-256 and, when one exists and remains current, the click identifier. This is optional, does not enable remarketing and can be withdrawn using the contact details in the privacy policy.

Anti-spam verification

It will load when you start completing the form.

Usual reply within one business day.

Continue the assessment