Skip to main content

Credit information systems · Case law of the Provincial Courts of Appeal

Credit default registers: the 5 mistakes for which the Provincial Courts of Appeal are finding against Spanish companies

Every defective entry is costing between 3,000 and 10,000 euros plus costs, as an indicative range. The case law that decides these disputes is not in the textbooks. It is here.

What companies are paying for registering a debtor badly

Registering a debtor in a credit default register is, in most companies, a routine step. It is triggered by non-payment, carried out by the recovery department or the outsourced platform, and reviewed by nobody. That routine step now has a price in court: when the entry does not survive scrutiny by a Provincial Court of Appeal (Audiencia Provincial), the creditor company is ordered to compensate the person registered. Not for the non-payment, which is usually real. For the way it was registered.

The indicative range in these disputes: awards of between 3,000 and 10,000 euros plus costs for each defective entry, with an indicative average award of around €4,500. These are reference points, not promises: every case turns on its own circumstances.

The unit figure is not the real problem. The real problem is the multiplier. There are firms working on a no-win-no-fee basis that have industrialised this type of claim: they find one defect in a company's registration process — a generic clause, the absence of a prior demand, a disputed debt — and turn it into a series of virtually identical claims, one for each person affected. If your company makes the same mistake in all of its standard contracts, you do not have one potential lawsuit: you have as many as you have registered debtors. The question stops being "can they find against me?" and becomes "how many times?".

This page sets out the five specific mistakes for which the Provincial Courts of Appeal are finding against companies, with the judgment that supports each one. Nothing stated here lacks a cited decision, with the court, number and date.

Why this case law does not appear in the usual guides

There is a structural reason why your usual advisers may not have warned you. In financial terms, claims for improper registration in credit default registers are modest-value cases. Around 98% of them end at the Provincial Court of Appeal: barely 2% reach the Supreme Court. And the textbooks, the annotated databases and the usual doctrinal summaries are built, almost always, on Supreme Court case law.

The result is a dangerous asymmetry. The case law that actually decides these disputes — that of the Provincial Courts — is not systematised in the general guides, nor on the website of the Spanish data protection authority (AEPD), which deals with the administrative route and not with the civil compensation you will end up paying. The party that does know it, criterion by criterion and division by division, is the firm bringing serial claims. It knows the yardstick you will be measured by. Most defendant companies do not. This page exists to correct that asymmetry: certainty about the exact criteria by which you will be judged.

The 5 mistakes that are costing money

Mistake 1 — Generic clauses: "credit default registers" identifies nothing

The financial consequence is the most direct of the five. If the contract from which the debt arises does not identify the specific register to which the data will be reported, and you registered the debt without first sending a payment demand, an adverse judgment is all but certain. It does not matter that the debt is real. It does not matter that the customer has not paid. What is compensated is the defective entry; the non-payment itself is not in issue.

The reasoning of the courts is simple. The duty to inform under Article 13 GDPR requires you to tell the customer, in the contract itself, which specific credit information system (CIS) their data will go to if they stop paying, together with the rest of the information the provision requires — in particular that in paragraphs 1(e) and 2. Standard-form clauses ("your data may be reported to credit default registers", "solvency registers") do not discharge that duty. And where the contract does not discharge it, the obligation to demand payment before registering revives, on a joint reading of Article 13 GDPR with Article 20 of the LOPDGDD (the Spanish Data Protection Act).

This is not an isolated view. The Vizcaya Provincial Court of Appeal alone repeated it six times in 2022 (SAP Vizcaya 136/2022, of 27 May; 265/2022, of 15 June; 292/2022, of 7 July; 197/2022, of 12 July; 225/2022, of 8 September; and 319/2022, of 7 September), and the Orense court had established it earlier (SAP Orense 629/2021, of 29 December).

SAP Vizcaya 265/2022, of 15 June
Creditors must send the prior payment demand where the contract has not stated the specific CIS in which that creditor participates, in addition to the rest of the information set out in Article 13 GDPR. [translation]
SAP Vizcaya 292/2022, of 7 July
Clause 11 of the contract neither sets out nor mentions the identification of the systems in which it participates. That is to say, it does not set out the identification of the registers (...), and the mere generic reference (...) is not sufficient for the alternative to the prior payment demand to be regarded as satisfied. [translation]

In operational terms: review the data protection clause in your standard contracts today. If it does not name the specific register, every entry made without a prior demand is a potential claim. And because the defect lives in the contract template, it repeats across the whole portfolio.

Mistake 2 — Reporting disputed debts as if they were beyond doubt

The second route to an adverse judgment: registering a debt the customer disputes. The invoice challenged in writing, the penalty the customer denies owing, the balance that depends on a contested settlement. None of that can be registered while the dispute exists, even if you are convinced you are right and even if a judge later agrees with you on the substance of the debt.

The basis is the data accuracy principle in Article 5 GDPR: the data reported to a credit information system must be genuine, accurate, truthful and permanently up to date. Only debts that are certain, due, payable and beyond doubt may be reported; those that are uncertain, in dispute or contested are excluded. And the breach does not stop at the GDPR: the Provincial Courts treat it as an unlawful act capable of also infringing the right to honour of the person registered, which is precisely what opens the door to compensation. That is the position taken, among others, in SAP Orense 629/2021, of 29 December, SAP Orense 385/2023, of 13 June, and the more recent SAP Orense 231/2026, of 10 April.

SAP Orense 231/2026, of 10 April
The case law takes the view that failure to meet these requirements amounts to a breach of the personal data accuracy principle enshrined in Article 5 of Regulation (EU) 2016/679. [translation]

In practice, this requires something almost no recovery process does: filtering, before every report to the register, whether there is any complaint, formal grievance or documented dispute about that debt. If there is, the entry must wait. Registering a disputed debt "to apply pressure" is, today, buying a lawsuit you will lose.

Mistake 3 — Complying, but not being able to prove it

In these disputes the winner is not the party that complied. It is the party that can prove it complied. That difference costs money: the burden of establishing the lawfulness of the processing, the accuracy of the data and the diligence applied falls on the company, not on the individual. It is the accountability principle in Article 5(2) GDPR.

SAP Asturias 412/2024, of 3 October
Under Article 5(2) GDPR, the controller shall be responsible for, and be able to demonstrate compliance with, paragraph 1 ("accountability"). [translation]

SAP Madrid 123/2026 applies the same logic to Article 6(4) GDPR: it is for the controller — for you — to determine and demonstrate that the purpose of the processing is compatible. Translated into day-to-day practice: if your company does not keep the signed contract with the information clause, the prior payment demand and proof that it was sent, and the file documenting that the debt was certain and payable on the date of the entry, you will arrive at the hearing empty-handed. And with the burden of proof against you, empty-handed means an adverse judgment. The evidence file is not bureaucracy: it is the difference between winning and paying.

Mistake 4 — Using "legitimate interests" as a wildcard

Many companies believe that invoking the legitimate interests basis in Article 6(1)(f) GDPR is enough to justify reporting data to the register. It is not, and the mistake is expensive: where legitimate interests are relied on without an assessment to support them, the processing is declared unlawful and the compensation follows the path already described.

The Provincial Courts require the disclosure to pass a cumulative three-part test: necessity (there is no less intrusive alternative to achieve the same purpose), suitability (the measure is genuinely effective for that purpose) and proportionality in the strict sense (the commercial interest does not override the rights of the individual). Fail one, and the whole basis of lawfulness fails. That is the position in SAP Madrid 123/2026 and SAP Madrid 148/2026, in line with what SAP Barcelona 72/2021, of 15 February, had already indicated.

SAP Madrid 123/2026
The application of Article 6(1)(f) requires that there be a legitimate interest of the controller or of the third party; that the processing be necessary to satisfy the legitimate interest pursued; and that, in weighing the legitimate interest against the impact it has on the interests of the individual concerned, the former prevails. [translation]

The practical consequence: that three-part test must be carried out, in writing, before you register. A documented two-page balancing assessment, done once and applied to the whole process, is worth more in court than any argument improvised after the claim arrives.

Mistake 5 — Having no filters against identity impersonation

The scenario is more common than it seems: somebody enters a contract using another person's documents, the unpaid debt is generated in the name of the person impersonated, and your company registers them in the register. The person impersonated — who never contracted anything — sues. And you pay, even though you too were a victim of the fraud. Why? Because in data protection the controller's fault is presumed (Article 82(3) GDPR): to be relieved of liability, the company must establish that it applied adequate measures of diligence to prevent this type of breach. If you cannot prove your identity verification controls, you are liable.

SAP Madrid 273/2024
For the processing to be lawful and not give rise to liability, the controller must demonstrate that it applied adequate due diligence measures to prevent breaches (such as impersonation), since fault is presumed unless a complete absence of responsibility for the harmful event is established (Article 82(3) GDPR). [translation]

The same decision recalls that processing inaccurate data that gives a misleading picture of the individual's situation infringes the rules. In other words: the anti-fraud filter is not only a defence against the impersonator; it is a condition of the lawfulness of your own processing. A documented verification procedure — and proof that it was applied to every new account — is what separates release from liability from an adverse judgment.

One final point worth keeping in mind: when the individual exercises their right to erasure under Article 17 GDPR, the reply also has a deadline and a required form, and handling it badly adds another front to the same dispute. We deal with it in detail on its own page.

Quick self-assessment: three questions

Answer yes or no, honestly. There is nothing to write down.

  1. Do your standard contracts identify, by its specific name, the credit default register to which the data will be reported in the event of non-payment? If the clause refers to "credit default registers" in general terms, the answer is no.
  2. Does your recovery process filter out debts disputed or challenged by the customer before each entry? If the report to the register is automatic X days after non-payment, the answer is no.
  3. Could you produce tomorrow, for any entry made in the last two years, the signed contract, the prior demand with its acknowledgement of receipt, and the file establishing that the debt was certain and payable? If you would have to go looking for it, the answer is no.

If you answered "no" — or "I don't know" — to any of the three, your exposure is not theoretical: it is exactly the pattern that serial claims are exploiting. The logical next step is to measure it precisely with the Exposure Test.

Measure your real exposure in ten minutes

The Exposure Test goes through, one by one, the criteria a Provincial Court of Appeal would use to examine your entries: contract, demand, data accuracy, evidence and diligence. At the end you will know what defects your process has and which to fix first. No personal data, no commitment.

Take the Exposure Test

Three ways to remove the risk

Flash Exposure Audit

We review your standard contracts and your registration process against the same criteria the Provincial Courts apply. A report on the defects a serial claimant would exploit, prioritised by financial risk.

See the Flash Audit

Contract Hardening

We rewrite the information clause, the prior demand and the registration protocol so that every new entry in the register passes the five judicial filters and is documented.

See Contract Hardening

Serial Claims Defence

If the claims have already started arriving, we build a unified defence strategy for the whole series: same case law, same evidence, cost per file under control.

See Serial Claims Defence
diagnostico
Credit default registers: the 5 mistakes that cost you | ILP Abogados