VERI*FACTU validation against the AEAT sandbox
An anonymised technical case covering a product release that completed creation, cancellation, controlled rejection and correction before commercial use was enabled.
Case reviewed
- Evaluated release
- 0.12.1
- Environment
- AEAT external test portal
- Outcome
- Positive and negative lifecycle completed with per-version evidence
Context
The evidence belongs to one release and one protocol. It demonstrates technical implementation and validation capability; it does not turn the result into a universal certification.
01
Starting point
Release 0.12.1 changed product behaviour outside the fiscal XML, but the release protocol required the full validation to run again before commercial invoicing could be enabled. The previous version’s declaration was not reused.
The objective was not a single accepted response. The release needed a complete fiscal lifecycle, imported evidence and a new responsible declaration associated with that version.
02
Protocol executed
The check combined positive and negative paths so the result was reproducible and useful in operation.
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.
03
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.
Commercial enablement only happened after tests passed, evidence was associated with 0.12.1 and the 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.
04
What has been removed from this case
This publication contains no tax identifiers, invoices, certificates, secure verification codes, fingerprints, private endpoints or operational identifiers. It also does not identify the owner of test data.
Only the validation sequence needed to explain the applied technical standard is retained.
Verifiable outcome
Closure combined external evidence, release control and recoverability. Sensitive detail remains outside this publication.
- 01Creation accepted in the external test environment.
- 02Cancellation accepted with the expected sequence.
- 03Controlled rejection followed by an accepted correction.
- 04New responsible declaration signed and held for release 0.12.1.
Common questions
Short answers about scope, evidence and implementation boundaries.
Does this case demonstrate AEAT certification?+
No. It demonstrates that a specific release completed a technical protocol in the external test environment and retained its evidence. The responsible declaration belongs to the system 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 defining the checked requirements. Private sandbox evidence is not published.
- 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
A useful protocol starts with the release and its risks.
Share the architecture, intended mode and implementation state. The first review will separate what is already demonstrated from what still needs evidence.