Did the CJEU SCHUFA ruling ban SCHUFA?

No. The ruling didn't declare SCHUFA scoring itself unlawful but found that the score calculation is automated individual decision-making under Art. 22 GDPR when the score is decisive in a third party's decision. SCHUFA and comparable credit bureaus continue to operate, but under tighter transparency, access, and justification obligations. Substantive use of such a score now also requires one of the Art. 22(2) exceptions (consent, contract, legal basis).

Is kvit a high-risk AI system under the EU AI Act?

No. Annex III §5(b) covers AI systems intended to evaluate the creditworthiness of natural persons or establish their credit score. kvit evaluates invoices as contractual documents — the subject of the score is the document and the commercial relationship, not the natural person. We do process personal data (debtor contact information), but the system makes no statement about that person's creditworthiness.

What's the practical difference between invoice-scoring and person-scoring?

It's in the data model, the inputs, and the output. Person-scoring takes personal attributes (location, prior credit, online behaviour, demographics) and outputs a value intended to say something about the person. Invoice-scoring takes invoice-specific attributes (amount, days overdue, response to prior Mahnungen on this invoice) and outputs a value intended to say something about the probability that this invoice gets paid. The same person with two different invoices can have two different invoice scores without that judging the person.

As a kvit customer, do I need a Data Protection Impact Assessment?

Not automatically. A DPIA under Art. 35 GDPR is required where processing is likely to result in a high risk to the rights and freedoms of natural persons. For the standard B2B configuration (legal-entity debtors, kvit processing only the contact details of the named contacts for Mahn communication) the DPIA obligation is generally absent. We make a pre-filled risk assessment available on request so the DPIA review is efficient if your DPO considers one necessary.

What if EU regulation shifts and Annex III §5(b) is extended?

We track regulatory development continuously. Should payment-behaviour scoring one day be explicitly added under Annex III, we would meet the high-risk obligations — conformity assessment, risk management, EU-database registration. The fundamental architecture (score at the contract, not at the person) would remain even then, because independent of regulation it is the operationally and ethically cleaner solution. Customers would be informed early; existing contracts would not be burdened retroactively.

How can I tell if my existing receivables software is EU AI Act-compliant?

Four indicators. (1) Has the vendor issued a written AI Act classification — and do they name Annex III §5(b) explicitly? Silence is suspicious. (2) How is the data model organised — is there a **debtor_credit_score** field or an **invoice_default_probability** field? The latter is clean, the former risky. (3) Which external creditworthiness data sources are pulled — SCHUFA, Creditreform, Bisnode? Those sit in the person-evaluation zone. (4) Is there a sub-processor list, a DPA template, written EU data residency? If not, the compliance architecture is patchy regardless.

Architecture

SCHUFA, the EU AI Act, and why kvit scores invoices — not persons

Kyle Nelson8 June 2026

The 2023 CJEU SCHUFA ruling and the entry into force of the EU AI Act in 2024 reshaped the legal envelope for automated scoring in the EU. Anyone evaluating an AI-based receivables tool should understand where the line between high-risk system and non-high-risk software now runs — and the architectural decisions that sit on either side of it. This piece sets out the legal landscape precisely and explains why kvit was built from the first commit to score invoices, not persons.

What the CJEU SCHUFA judgment actually said

On 7 December 2023, the European Court of Justice ruled in C-634/21 (OQ v. Land Hessen, concerning SCHUFA) that the automated calculation of a probability value about a natural person's ability to pay constitutes automated individual decision-making within the meaning of Article 22(1) GDPR — as soon as that value plays a decisive role in a subsequent decision by a third party.

Concretely: when a bank substantially bases its credit decision on a SCHUFA score, it isn't only the bank's decision that engages Article 22 — the score calculation itself does. SCHUFA becomes a controller under Article 22 GDPR, not only the bank that queries the score.

The immediate practical consequences:

Automated person-scoring is no longer trivially permissible. It requires one of the Article 22(2) exceptions: explicit consent, contractual necessity, or a national legal basis.
Score providers carry responsibility. Selling person-scoring to third parties no longer hides behind the third party's downstream decision.
Transparency and access rights tighten. Data subjects are entitled to meaningful information about the logic of the scoring (Art. 15(1)(h) GDPR).
Similar setups are covered. The ruling extends well beyond SCHUFA — to any software that calculates personal probability values and supplies them to third parties for substantive decisions.

EU AI Act Annex III §5(b) — the next layer

The EU AI Act (Regulation 2024/1689) entered into force on 1 August 2024, with staggered application dates running to 2027. Annex III lists the AI applications classified as high-risk and therefore subject to the obligations of Chapter III.

Annex III §5(b) covers:

AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score, with the exception of AI systems used for the purpose of detecting financial fraud.

What that classification triggers when it applies:

Conformity assessment before placing on the market (Art. 43) — either internal or via a notified body, depending on use case.
Risk management system across the full lifecycle (Art. 9).
Data governance with requirements on training, validation and test data (Art. 10).
Technical documentation (Art. 11) and logging (Art. 12).
Transparency to users (Art. 13) and human oversight (Art. 14).
Registration in the EU database (Art. 49) and CE marking.
Post-market monitoring and reporting of serious incidents (Arts. 72, 73).

What Annex III §5(b) actually costs

Those obligations are not symbolic. Placing a high-risk system on the market under Art. 6(2) AI Act effectively means building a second compliance organisation alongside the actual product:

A conformity assessment takes six to eighteen months depending on complexity. The ongoing obligations — risk management, technical documentation, logging, post-market monitoring — are not one-off events but persistent functions that require staffing. Industry estimates put the annual cost for a mid-sized high-risk AI system in the high six figures.

That isn't wrong or unfair — for a system that affects a person's life chances (credit access, tenancy, insurance) the obligations are substantively justified. But they are a deliberate threshold the legislator set. Avoiding them by building the system differently, rather than making it conform, is not regulatory arbitrage — it's using the differentiation the legislator built in.

The architectural decision: score invoices, not persons

kvit calculates a score — a probability value that an invoice will be paid within a given time. But the subject of that score is the invoice as a contractual document, not the natural person who happens to be the debtor.

Concretely:

Inputs are invoice-specific: amount, days overdue, prior Mahn stages on this specific invoice, channel-response behaviour on this invoice, sector and business model of the debtor as a legal entity.
Inputs are explicitly NOT: SCHUFA scores or comparable external creditworthiness signals, personal data of the natural persons behind the debtor company, place-of-residence data, online behaviour, individual payment-history profiles.
Output is an invoice attribute: the score lives in the invoice record, not in a person or debtor_contact record. It informs the dunning strategy for this specific invoice — it is not a general statement about a human's creditworthiness.
Application context is B2B receivables. The debtor side is predominantly a legal entity (a company), which is not within the protective scope of Art. 22 GDPR. Where natural persons are debtors (consumer remnants), additional care applies — see next section.

Why this is more than legal cosmetics

The distinction between invoice-scoring and person-scoring has three concrete operational consequences for anyone deploying kvit as a tool:

No high-risk obligations. Because the system doesn't fall under Annex III §5(b), the full obligations catalogue in Chapter III of the AI Act doesn't apply — no conformity assessment, no EU-database registration, no CE marking, no post-market monitoring at that level. That keeps the product cheaper and faster to evolve without undermining the protective goals.

Lighter Data Protection Impact Assessment. A DPIA under Art. 35 GDPR is not automatically required. It can be sensible depending on deployment (B2B with sole proprietors, very large data volumes), but it isn't a strict requirement absent specific risk.

No Article 22 conflict. Because kvit doesn't make automated decisions about natural persons (it decides which Mahn action follows on which invoice), the system doesn't collide with Art. 22(1) GDPR. The legal framework simplifies considerably.

Where we're transparent: the limits of this architecture

Intellectual honesty demands naming the limits too:

Personal data is processed — debtor contact data (name, email, phone, address) necessary for Mahn communication. That processing runs under Art. 6(1)(b) GDPR (contract performance / pre-contractual measures) or Art. 6(1)(f) (legitimate interest). The GDPR obligations — information, access, deletion, data residency — apply in full.

When the debtor is a natural person (sole proprietors, freelancers, consumer receivables), the use case approaches the line. We treat these cases with additional care: no blanket creditworthiness statement, no storage of scores on the person profile, every human-overridable decision stays human-overridable.

The score informs workflow decisions but is human-overridable. Which Mahn stage runs next, which channel is used, when to hand off to the partner for the court Mahnverfahren — every step has a human approval available. The score proposes, the human decides.

Every automated action is hash-chain logged. Even though that doesn't follow from the AI Act high-risk classification — we implemented the end-to-end, immutable audit log from the first commit, because it should be the default for compliance reviews, audit trails, and plain good engineering.

What this means for buyer diligence

If you are a CFO, DPO, or legal counsel evaluating an AI receivables tool, five targeted questions separate signal from noise:

What exactly does the system evaluate — the natural person or the invoice / contract? The answer must be precise, with reference to the data-model fields.
Which inputs feed the score? In particular: are there SCHUFA pulls, creditworthiness signals from external sources, personal behavioural data of natural persons?
Did the vendor perform an AI Act conformity assessment? If yes, why was it needed? If the system isn't high-risk, the honest answer is: no, it wasn't needed.
Where does the data live and who are the sub-processors? EU data residency in 2026 is market standard, not premium feature. Sub-processors must be listed and contractually bound.
How is a single automated action documented? A baseline audit log is the minimum; hash-chain-secured logging is better. For GDPR access requests you have to be able to reconstruct every step.

What happens if the legal landscape shifts

Regulation here is not static. At least three Brussels movements could touch this architecture:

Revision of the DPIA list by national supervisory authorities — some explicitly add receivables management to the mandatory-DPIA list, raising the bar without touching the AI Act itself.

Brussels discussions about Annex III extensions. There are lobbying efforts to add payment behaviour scoring explicitly under Annex III. That would be a substantive shift — and the main reason we keep the architecture documented and versioned.

National implementation specifics in Germany, Austria, Switzerland. Some authorities go stricter than the EU baseline; we track per market.

Worst case: if our architecture one day did fall under Annex III §5(b), we would add explicit consent flows per debtor and meet the additional high-risk obligations. But the fundamental structure — score at the contract, not at the person — we would not change. Independent of regulation it is the more honest answer to the underlying problem.

Frequently asked questions

Did the CJEU SCHUFA ruling ban SCHUFA?: No. The ruling didn't declare SCHUFA scoring itself unlawful but found that the score calculation is automated individual decision-making under Art. 22 GDPR when the score is decisive in a third party's decision. SCHUFA and comparable credit bureaus continue to operate, but under tighter transparency, access, and justification obligations. Substantive use of such a score now also requires one of the Art. 22(2) exceptions (consent, contract, legal basis).
Is kvit a high-risk AI system under the EU AI Act?: No. Annex III §5(b) covers AI systems intended to evaluate the creditworthiness of natural persons or establish their credit score. kvit evaluates invoices as contractual documents — the subject of the score is the document and the commercial relationship, not the natural person. We do process personal data (debtor contact information), but the system makes no statement about that person's creditworthiness.
What's the practical difference between invoice-scoring and person-scoring?: It's in the data model, the inputs, and the output. Person-scoring takes personal attributes (location, prior credit, online behaviour, demographics) and outputs a value intended to say something about the person. Invoice-scoring takes invoice-specific attributes (amount, days overdue, response to prior Mahnungen on this invoice) and outputs a value intended to say something about the probability that this invoice gets paid. The same person with two different invoices can have two different invoice scores without that judging the person.
As a kvit customer, do I need a Data Protection Impact Assessment?: Not automatically. A DPIA under Art. 35 GDPR is required where processing is likely to result in a high risk to the rights and freedoms of natural persons. For the standard B2B configuration (legal-entity debtors, kvit processing only the contact details of the named contacts for Mahn communication) the DPIA obligation is generally absent. We make a pre-filled risk assessment available on request so the DPIA review is efficient if your DPO considers one necessary.
What if EU regulation shifts and Annex III §5(b) is extended?: We track regulatory development continuously. Should payment-behaviour scoring one day be explicitly added under Annex III, we would meet the high-risk obligations — conformity assessment, risk management, EU-database registration. The fundamental architecture (score at the contract, not at the person) would remain even then, because independent of regulation it is the operationally and ethically cleaner solution. Customers would be informed early; existing contracts would not be burdened retroactively.
How can I tell if my existing receivables software is EU AI Act-compliant?: Four indicators. (1) Has the vendor issued a written AI Act classification — and do they name Annex III §5(b) explicitly? Silence is suspicious. (2) How is the data model organised — is there a debtor_credit_score field or an invoice_default_probability field? The latter is clean, the former risky. (3) Which external creditworthiness data sources are pulled — SCHUFA, Creditreform, Bisnode? Those sit in the person-evaluation zone. (4) Is there a sub-processor list, a DPA template, written EU data residency? If not, the compliance architecture is patchy regardless.

Architecture documentation for your DPO

kvit makes the full data-model and data-flow documentation available to customers on request — sub-processor list, DPA template, AI Act classification, pre-filled DPIA. Write to legal@kvit.ai.

Request documentation