VERI*FACTU in my own invoicing
I built the system I use to invoice my freelance work. I have used it with VERI*FACTU from my first invoice, with records accepted by AEAT in production.
Case reviewed
- Context
- Software built for internal use in my freelance business
- Real use
- Records accepted in production from my first invoice
- Prior validation
- Creation, cancellation, rejection and correction in a separate test environment
Context
I needed to issue invoices, track payments, record expenses and prepare information for my accountant. VERI*FACTU is part of that workflow. This case distinguishes technical testing from real use without disclosing the software’s identity or access details.
01
A tool for running my business
I designed and built a private web application for my own workflow: preparing and issuing invoices, distinguishing invoiced amounts from payments received, recording expenses and exporting information for my accountant to review.
Issuing an invoice needed to preserve its history and make the AEAT response available. An outstanding payment or an email sent to a client should not be confused with the status of the fiscal record.
02
What has been demonstrated in production
The first invoice issued through the system generated a VERI*FACTU record accepted by AEAT. At the time of this review, the issued invoices retain their production acceptance responses.
This is evidence of real use in my business, not a high-volume test or a guarantee for other companies. Each adaptation needs its own review, testing and documentation.
- Real invoicing and record submission, without simulation mode.
- Acceptance responses and receipts retained privately.
- A signed responsible declaration held for the version in use.
03
What was tested in the AEAT environment
Creation, cancellation, rejection and correction were tested in the external test environment, separate from real invoicing. They are not presented as commercial transactions.
01
Creation and cancellation
Creation and cancellation records were submitted to the external test environment and both were accepted.
02
Controlled rejection
A known rejection was triggered to verify validation, response capture and preservation of the record context.
03
Correction
The flow linked the correction to the previous record and confirmed acceptance without rewriting the historical chain.
04
Evidence and closure
The evidence package for the release was imported once. A new responsible declaration was then generated, externally signed and checked for signature, identity, integrity and absence of active content.
The protocol required validation to be repeated for the evaluated release. Commercial invoicing with that release was enabled only after tests passed, evidence was associated with it and a new signed declaration was placed in custody.
- Evidence remained linked to the evaluated release.
- No invoice or historical chain was modified to complete the protocol.
- Environments, certificates and artefacts remained separate.
- A subsequent restore confirmed that declaration and evidence were recoverable.
05
What stays private
The software’s name, domain, access links, repository and identifying details are not published. Neither are invoices, clients, amounts, tax identifiers, certificates, verification codes or operational identifiers.
The case explains the work and the verified outcomes. It demonstrates development and integration experience, not a software package available to buy.
Real use and testing, with clear boundaries
Use in my business and technical testing provide different evidence. Neither is presented as AEAT approval or a guarantee for another system.
- 01Production: records from my real invoicing accepted by AEAT.
- 02Testing: creation and cancellation accepted in AEAT’s external test environment.
- 03Testing: controlled rejection followed by an accepted correction.
- 04Documentation: signed responsible declaration and release evidence held privately.
Common questions
Short answers about scope, evidence and implementation boundaries.
Is this a test example or do you use it to invoice?+
I use it for my own freelance invoicing, with records accepted by AEAT in production from the first invoice. Cancellation, rejection and correction tests were carried out separately in the test environment.
Does this case demonstrate AEAT certification?+
No. It demonstrates real use and a technical testing protocol with retained evidence. Accepted records do not mean AEAT has approved the software; the responsible declaration belongs to the producer.
Can the evidence be reused for another product?+
No. Architecture, flows, version and producer differ. The protocol can be reused as a method, but evidence must be obtained for the system being evaluated.
Why were tests repeated if the XML did not change?+
Because fiscal enablement was tied to the application release. That rule prevented a new release from automatically inheriting a previous declaration and evidence.
Official framework
References for the technical framework. Test and production responses and documents are retained privately, not published here.
- VERI*FACTU technical information and schemas
AEAT · Spanish source on services, schemas and validation errors
- Royal Decree 1007/2023, consolidated text
BOE · Spanish legal text on integrity, traceability and declarations
- Order HAC/1177/2024, consolidated text
BOE · Spanish legal text on technical specifications
Related routes
Does your business need something similar?
Tell me which software you use and what still needs adapting. We can review what can be retained and what needs development, without assuming the conclusions of this case apply to yours.