The platform's legal and fiscal obligations
Te Lo Llevo operates in Spain and, as a commerce and invoicing platform, is subject to fiscal obligations, data protection requirements and access control rules. This chapter documents those obligations and how they are addressed in the platform's design.
Compliance is not optional. This chapter explains what Veri*Factu is and why the platform must prepare for it, how the personal data of customers and couriers is managed, what the audit trail is and why it is non-negotiable, and what the legal framework is for selling alcohol and tobacco.
Veri*Factu
Veri*Factu is the Spanish anti-fraud invoicing regime established by Ley 11/2021 ("Ley Antifraude"), developed by Real Decreto 1007/2023 and further specified in Orden HAC/1177/2024. It applies to all software that issues invoices to end consumers — what the regulation calls a Sistema Informático de Facturación (SIF) (Billing Software System). The Te Lo Llevo POS issues receipts to end consumers and therefore falls squarely within its scope.
Murcia falls under the common territory regime (AEAT jurisdiction), which means Veri*Factu applies — not the specific Basque Country regime (TicketBAI). This distinction is important: the obligations, the technical format of the records and the submission channel to the Spanish Tax Agency are those set out in the national regulation.
As of this document, Veri*Factu is a planned specification — not yet implemented in the platform. The POS design — gap-less invoice numbering, immutable records, a sequenced and locked Z report — is conceived to facilitate this integration. However, actual submission of records to the AEAT and inclusion of the QR code and the "VERI*FACTU" legend on the printed receipt are features planned for a future phase.
What Veri*Factu requires
Hash-chained records
Each invoice record must contain a hash of the previous record, forming an unalterable chain. Retroactively modifying a receipt would break the chain and would be detectable.
Fiscal immutability
Issued receipts cannot be deleted or altered. Any correction is made via a credit note or rectification document expressly linked to the original.
Near-real-time submission to the AEAT
Each invoicing record must be sent to the Spanish Tax Agency within the maximum period set by the regulation after issuance. This requires connectivity with AEAT services.
QR code and legend on the receipt
The printed receipt must include a QR code allowing the invoice to be verified on the AEAT electronic portal, together with the legend "VERI*FACTU".
Why the current design already considers Veri*Factu
Although the technical integration with the AEAT is still pending, the POS already operates according to several principles that Veri*Factu imposes:
- Gap-less numbering: the receipt sequence is consecutive and does not allow gaps or deletions.
- Receipt immutability: an issued receipt cannot be edited; refunds generate a new credit note document linked to the original.
- Numbered and immutable Z report: session close produces a Z report with its own sequence number that cannot be modified.
- Audit trail: all sensitive accesses and changes are recorded with user, timestamp and detail.
Invoices & receipts
Spanish regulations distinguish two types of sales document: the simplified receipt (factura simplificada) and the full invoice (factura completa).
| Type | When used | Recipient data | Fiscal use |
|---|---|---|---|
| Simplified receipt (ticket) | Standard over-the-counter sale to an end consumer | Does not require the customer's tax ID (NIF) or address | Valid for the consumer. Not deductible for a business. |
| Full invoice | When the customer needs an invoice for their business | Requires the recipient's tax ID (NIF) and address (captured by the cashier) | Tax-deductible for the recipient when acting as a trader or professional. |
Both document types include VAT itemised by tax rate, a sequential invoice number, the issuing merchant's details (name, VAT number, address) and a description of the items sold with their amounts. The main distinction is whether or not the recipient's data is captured.
Orders placed through the customer app also carry VAT calculated by the system
according to the tax code of each product (IVA_SUPER_REDUCED 4 %,
IVA_REDUCED 10 %, IVA_STANDARD 21 %,
EXEMPT 0 %). VAT is visible in the order breakdown and in the
customer's order history.
Data protection (GDPR)
Te Lo Llevo processes personal data belonging to customers, couriers and, to a lesser extent, merchant representatives. The EU General Data Protection Regulation (GDPR) and the applicable Spanish implementing legislation apply directly. The platform incorporates specific capabilities to fulfil data subjects' rights and to meet data retention and minimisation obligations.
Data subject rights
Right of access / data export
A customer or courier can request an export of all their personal data held by the platform. The Operations console handles these requests and generates the data package.
Right to erasure / data deletion
A customer or courier can request the deletion of their data. The Operations console processes the request. Data subject to a fiscal retention obligation is not deleted until the legal retention period expires.
Retention policies
Not all data can be deleted immediately. Spanish tax legislation requires accounting documents and invoices to be kept for at least four years (the general tax prescription period). Accordingly, the platform applies differentiated retention policies:
- Account and profile data: deleted within the agreed period after an erasure request, unless linked to transactions still under fiscal retention.
- Order history and receipts: retained for the mandatory fiscal retention period. Once the period has elapsed, erasure can be completed.
- Audit trail records: retained according to periods defined by the data controller, in line with applicable legal and security obligations.
Retention policies are executed automatically on scheduled runs. The Operations team can review the status of pending requests and retention periods from the compliance console.
What personal data the platform processes
| Category | Data processed | Main legal basis |
|---|---|---|
| Customers | Name, phone, email address, saved addresses, order history, tokenised payment method. | Performance of a contract; legitimate interest. |
| Couriers | Name, phone, email address, identity documents (KYC), location during service, task history, cash on hand. | Performance of a contract; legal obligation (KYC). |
| Merchants / cashiers | Responsible person's name, merchant VAT number, bank details for payouts, POS session history. | Performance of a contract; legal obligation (invoicing). |
Age verification for restricted products (alcohol, tobacco) is carried out solely through the cashier's attestation. The system does not capture or store the customer's name, ID document number or any copy of their identity document. Only the cashier's declaration that the customer meets the age requirement is recorded.
Security & secret rotation
The credentials, API keys and other secrets the platform uses to operate must be renewed regularly. This process is called secret rotation and is part of sound operational security practice.
The primary reason for rotation is to limit the damage if a credential is compromised without anyone detecting it immediately: if secrets are rotated periodically, the validity window of a leaked credential is bounded. Rotation also ensures that credentials belonging to people who have left the team are no longer valid.
Rotation policies
The Operations console provides a secret rotation panel where the Operations team can see the status of each credential, when it was last rotated and when it is next due for rotation.
Why it matters
An unrotated secret is a silent failure point. Keeping credentials fresh reduces the attack surface and ensures that only currently authorised people and systems hold active access.
Rotation policies are part of the platform's security plan. Ignoring rotation alerts or postponing credential renewal increases the risk of unauthorised access and can compromise the integrity of customer, courier and merchant data.
The audit trail
Every sensitive action carried out on the platform is recorded in the audit trail. This is an append-only log — it is never deleted or edited — that makes it possible to reconstruct exactly who did what, when and from which access point.
What is recorded
| Area | Examples of audited events |
|---|---|
| POS / till | Session open and close, every sale, refund, discount applied, inventory adjustment, cash drawer opening without a sale, Z report issuance. |
| Couriers | Task state changes (accept, pick up, arrive, deliver, return-to-origin), cash settlements, account activations and deactivations. |
| Operations / admin | Merchant and courier onboarding, platform configuration changes, payout approvals, GDPR data request management, secret rotation. |
| Payments | Refunds, cancellations, order voids, changes to a customer's saved payment methods. |
Each audit trail entry includes: the identifier of the user who carried out the action, the exact date and time (with time zone), the action performed and, where applicable, the before and after values of any change.
No user — not even the Operations team — can modify or delete entries from the audit trail. This is fundamental to fiscal compliance (Veri*Factu), to responding to inspection requests and to managing security incidents.
Age-restricted sales
Ley 28/2005 on health measures against tobacco use and complementary minor-protection regulations prohibit the sale of alcohol and tobacco to persons under 18 years of age. This prohibition covers both over-the-counter sales and, under the prevailing interpretation, online sales.
The control at the POS
When a sale basket contains at least one item marked as age-restricted (alcohol or tobacco), the POS interrupts the checkout flow and displays an age attestation screen. The cashier must expressly confirm that:
- The customer is 18 years of age or older.
- If the customer appears to be under 25, a valid identity document has been requested and checked.
Only after this confirmation does the system allow the sale to continue. If the cashier dismisses the attestation screen, the sale cannot be completed for the restricted items.
The system does not store any personal data about the customer arising from the age verification: not the name, not the document number, not any image or copy of the document. The only record created is the cashier's attestation (who confirmed it and when), which forms part of the sale's audit trail.
The control in the customer app (online orders)
For online orders that include age-restricted products, the customer must accept an age declaration when completing the order. When delivering the order, the courier must verify that the recipient meets the age requirement, following the same attestation principle as at the POS.
Roles & least privilege
Access control is one of the most effective tools for reducing operational risk and meeting regulatory requirements. Te Lo Llevo applies the principle of least privilege: each user has access only to the functions they need for their job, and nothing more.
| Role | Sensitive actions permitted | Actions not permitted |
|---|---|---|
STAFF |
Ring up sales, apply discounts up to 10 % or €10, print receipts, view the X report. | Refunds, larger discounts, inventory adjustments, no-sale drawer opens, Z report, configuration changes. |
MANAGER |
Everything STAFF can do, plus: inventory adjustments (with reason), discounts up to 50 %, no-sale drawer open (with reason), cash pay-in and pay-out. |
Full sale refunds, discounts above 50 %, full comps, merchant configuration changes, user management. |
OWNER |
Everything above, plus: sale refunds, unlimited discounts, full comps, complete merchant configuration, terminal and branch management, Z report. | — |
When a STAFF member attempts an action they are not permitted to
perform — for example, giving a 30 % discount — the system alerts them that the
action requires a higher level. A MANAGER or OWNER
present can authorise the operation with their own credentials without closing the
cashier's session. This authorisation is recorded in the audit trail linked to
that specific sale.
For a complete description of the role system, permissions and their practical implications, see the Roles & permissions chapter. For the POS details to which these roles apply, see the POS chapter.
Gap-less numbering, receipt immutability, an unalterable audit trail, secret rotation and the least-privilege principle are not afterthoughts. They are built into the platform's design from the start, precisely so that the future Veri*Factu integration and any response to an inspection request will be smooth and free of improvisation.