Modelo 170 — Spain’s monthly card and mobile-payment return
Modelo 170 used to be the return an acquiring team filed once a year and forgot about. Since January 2026 it is a monthly feed, per terminal, with mobile-number payments added to the scope. Real Decreto 253/2025 rewrote article 38 bis of the Spanish tax procedure regulation (RGAT, Real Decreto 1065/2007), and Orden HAC/747/2025 of 27 June 2025 approved a new modelo 170 to carry it. The first declaration under the new model covered January 2026 and was filed in February 2026. The old annual model under Orden EHA/97/2010 is repealed, except for periods before 2026. Any payment institution or e-money institution that signs up Spanish merchants now owes the tax agency twelve files a year, and each file shows where every merchant’s money lands.
1. Who files: acquirers, terminal providers, and passported firms
Article 38 bis.1 RGAT, in the wording in force from 1 January 2026, names two groups of obliged entity. Both are defined by the service they provide to businesses and professionals established in Spain, not by where the provider is licensed:
| Limb | Who | Service that triggers the duty |
|---|---|---|
| 38 bis.1(a) | Credit institutions and other entities that provide collection management | Collecting payments by card (physical or virtual; cash, debit, deferred debit, credit or e-money functions; any currency) or by payments linked to a mobile phone number |
| 38 bis.1(b) | E-money institutions, payment institutions and other entities | Providing point-of-sale terminals and executing collection transactions for merchants |
| Final paragraph | Spanish branches of EU or third-country entities in (a) and (b), and the same entities operating in Spain under the freedom to provide services | Collection management and terminal provision for merchants established in Spain |
The last row is the one that changes the map for passported firms. An acquirer licensed in another member state that serves Spanish merchants cross-border, with no Spanish branch, is inside the obligation. The pre-2026 regime was framed around card collection by credit institutions and similar entities. The new wording names payment and e-money institutions directly and adds terminal provision as a separate trigger.
The obliged-entity rule sits in the regulation; Orden HAC/747/2025 does not restate it. Article 11 of the order simply points back to article 38 bis.1, so any scoping memo should cite the RGAT article, not the order.
2. What is in scope, and what the agency has excluded
The AEAT’s FAQ on the 2026 model answers two scoping questions that come up in every implementation:
- No minimum threshold. Every card or mobile-number collection by a Spanish-established business or professional is reportable, whatever the amount. That is the opposite of the new card-issuer return, modelo 174, which excludes cards below €25,000 of annual debits and credits (see section 6).
- Person-to-person mobile payments are out. The obligation covers collections by businesses and professionals. Payments between private individuals over a mobile-number scheme are not declared.
The trigger is the merchant being established in Spain, not the location of the device. Article 38 bis.2(c) requires the point-of-sale terminals to be reported “whether or not they are in Spanish territory”. A Spanish merchant selling at a trade fair abroad on a terminal you supplied stays in the file.
3. What each record carries
Article 38 bis.2 lists five content items. Annex III of Orden HAC/747/2025 turns them into message fields. The structure is a header block (model, year, period 01–12, schema version 1.0, filer name and NIF, contact person) followed by a repeating block per declared merchant:
| Field group | Content | Notes |
|---|---|---|
| TipoComunicacion | A0 new record, A1 modification, A2 deletion | A1 and A2 correct records sent in error |
| IDRegistro | Your identifier for the detail record, up to 50 characters | This is the key for any later correction |
| DatosDeclarado | Merchant’s full name or company name and NIF | Legal representative’s name and NIF for a declared person under 14 |
| NumComercio | Merchant number used in the system, up to 20 characters | Required |
| IDCuenta | IBAN of the account that receives the collections, or, if there is no bank account, a payment-account identifier with type 1 (not internal to the entity) or 2 (internal) | Optional SWIFT/BIC |
| TPV (repeating) | Terminal number, total transaction count and monthly billed amount per terminal | Includes an IdCobro flag: T if each terminal’s collections map to one specific account, C if they do not |
| CobrosTfnoMvl | Transaction count and monthly billed amount for mobile-number collections | Separate from the card terminals |
Two design choices matter for your data model. First, amounts are per terminal, not per merchant, so your acquiring ledger needs a terminal dimension that survives into the reporting layer. Second, the account field is about the destination of the funds. Article 38 bis.2(e) asks for the bank or payment account the collections go to, “or any other destination”. The internal-account key (type 2) exists because many payment institutions settle merchants into accounts on their own books rather than to an external IBAN.
4. Filing window, channel and partial acceptance
Article 13 of the order sets the timing: monthly, filed during the calendar month after the month declared. January’s data goes in during February, and so on. There is no separate annual summary.
Article 18 sends the model through the AEAT’s electronic-message procedure under articles 16 and 17 of Orden HAP/2194/2013. Article 19 leaves the technical format and design to the AEAT’s electronic office. The same article 18 sets a partial-acceptance rule that shapes how you run corrections:
- If a submission contains errors, only the records with no reason for rejection are accepted.
- The response message lists the accepted and rejected records, with the reason for each rejection.
- If at least one record is accepted, the response carries a 16-character secure verification code (CSV) plus the date and time of filing.
- Rejected records have to be corrected and sent again.
So a month is not “filed” or “not filed”. It is filed for the accepted records, and the rest are open items until you resubmit. Your control log needs a status per record, not per file.
5. Three situations, and what the practitioner does
Scenario 1 — a Lithuanian-licensed EMI with Spanish merchants and no branch.
Facts: an e-money institution authorised in another member state onboards 1,200 Spanish shops through a passport notification under the freedom to provide services. It supplies soft-POS terminals and settles into e-money accounts on its own ledger. Its Spanish obligations inventory lists only the returns tied to an establishment.
What the rule says: the final paragraph of article 38 bis.1 covers entities operating in Spain under the freedom to provide services, for collection and terminal services to merchants established in Spain. Limb (b) catches the terminal provision on its own.
What the practitioner does: adds modelo 170 to the Spanish calendar as a monthly item. Confirms the firm holds a Spanish NIF to file under, since the header requires the filer’s NIF. Maps each settlement account to IDCuenta type 2 (internal), because the funds never leave the firm’s books. Then checks that every merchant record carries a valid Spanish NIF, because the declared merchant’s NIF is mandatory and nothing in the model lets you omit it.
Scenario 2 — one merchant, three terminals, two settlement accounts.
Facts: a restaurant group has three terminals. Two settle to one IBAN, the third to a second IBAN at another bank. The acquirer’s settlement engine nets fees before payout and cannot always tie a payout back to a single terminal.
What the rule says: Annex III reports amounts per terminal and asks, through the IdCobro flag, whether the filer can tie each terminal’s collections to one account (T) or not (C).
What the practitioner does: reports gross billed amounts per terminal from the transaction ledger, not net payouts from the settlement engine. Sets IdCobro honestly: T only where the routing is deterministic, C where netting or pooled payouts break the link. Documents the rule in the reporting manual so the flag does not drift between months.
Scenario 3 — a rejected batch in the middle of the month.
Facts: the March file goes in on 10 April. The response accepts 9,800 records and rejects 200 because the NIF does not match the tax agency’s census.
What the rule says: article 18.2 of the order accepts the clean records, issues a CSV for them, and requires the rejected ones to be corrected and resubmitted.
What the practitioner does: stores the CSV as evidence for the 9,800 records. Opens a remediation queue for the 200, split by rejection reason. Resubmits as A0 records before 30 April. If a record already accepted turns out to be wrong later, it goes back as A1 or A2 against the original IDRegistro, not as a fresh A0. That is why IDRegistro has to be stable and stored.
6. The neighbouring returns: 174, 196 and 171
Orden HAC/747/2025 is a package. Modelo 170 is one of four information returns it approves or amends. A firm that acquires and issues will touch most of them:
| Return | What it covers | Frequency | Legal basis |
|---|---|---|---|
| Modelo 170 | Merchant collections by card and mobile-number payments | Monthly | Art. 38 bis RGAT; arts. 10–13 of the order |
| Modelo 174 (new) | All types of cards issued: contract, PAN, holders, annual debits and credits, cash top-ups, withdrawals, linked IBAN. Cards under €25,000 of both annual debits and annual credits are excluded | Annual, filed 1–31 January | Art. 38 ter RGAT; arts. 14–17 of the order |
| Modelo 196 | Accounts, including payment and e-money accounts, with holders, authorised persons and beneficial owners | Monthly | Art. 37 RGAT; arts. 1–5 of the order |
| Modelo 171 | Cash deposits, withdrawals and collections of documents | Annual (order amended) | Art. 38 RGAT; Orden EHA/98/2010 as amended |
The practical point is that the account in modelo 170’s IDCuenta field is very often an account you already report in modelo 196. Build both from the same account master, so the IBAN or internal identifier is identical in both files.
FAQ
When did monthly modelo 170 start?
With the declaration for January 2026, filed in February 2026. The rule changes took effect on 1 January 2026 under Real Decreto 253/2025, and the new model was approved by Orden HAC/747/2025.
Is there a minimum amount below which a merchant is not reported?
No. The AEAT’s FAQ for the 2026 model confirms there is no threshold. All card and mobile-number collections by businesses and professionals established in Spain are reportable.
Do we report person-to-person mobile payments?
No. The AEAT has confirmed that payments between private individuals are excluded. Only collections by businesses and professionals count.
We are licensed elsewhere in the EU with no Spanish branch. Are we in scope?
Yes, if you provide collection or terminal services to merchants established in Spain. Article 38 bis.1 RGAT expressly covers entities operating in Spain under the freedom to provide services.
What if a merchant’s terminal is outside Spain?
Report it anyway. Article 38 bis.2(c) requires the terminals whether or not they are in Spanish territory. The test is where the merchant is established.
How do we correct a record that was accepted but wrong?
Send it again with TipoComunicacion A1 (modification) or A2 (deletion) against the original IDRegistro. A0 is for new records.
What does the old modelo 170 still govern?
Orden EHA/97/2010 is repealed but still applies to filings for periods before the new order took effect, which in practice means 2025 and earlier.
7. What to do, today
- Check scope by merchant establishment, not by your own licence. Passported acquirers and terminal providers are named in article 38 bis.1.
- Add a terminal dimension to the reporting layer. Amounts go in per terminal, and terminals abroad still count.
- Split card and mobile-number collections at source. They are separate amounts with separate counts.
- Store IDRegistro and the CSV for every month. Corrections key off the first, and the second is your evidence of filing.
- Reconcile modelo 170 accounts against modelo 196. The same destination account should carry the same identifier in both returns.
Related: Modelo 196 — Spain’s monthly account return · The Spanish reporting calendar · CESOP in Spain — modelo 379 · Modelo 174 — Spain’s annual card-issuer return
