Early access. Product screens use synthetic demo data; accounts and bank imports are not open yet. What is live today

Research

An AI receivables copilot: what we are researching, and what we will not build

There is no DIGITAL EUR AI assistant to use today. Matching stays rule-based. This page sets out what a future assistant could propose, what it would never decide, and how the EU AI Act and GDPR shape a human-in-the-loop design.

By Daniel Malbašić · Last reviewed

Short answer

An AI accounts receivable assistant uses a language model to explain, summarise or draft receivables work, such as why a payment was matched or what a reminder should say. DIGITAL EUR's copilot is a research topic and is not available. Our matching is rule-based; any future assistant would only propose, and a named person would approve every change.

What is an AI accounts receivable assistant?

The phrase covers a wide range of products. Reading vendors' own pages on 5 November 2026, we found four broad patterns:

Pattern What the AI does Examples of vendors describing it
Chat assistant for the finance team Answers questions about accounts, suggests next steps, drafts emails Gaviti describes an "agentic" assistant that helps with dunning emails, credit decisions and remittance matching
Collections co-pilot Prioritises accounts, sorts customer replies, drafts responses, may place calls Recovr describes recommendations per account, inbox sorting, drafted replies and AI calls, with approval for formal notices
Autonomous agent Monitors ageing, sends reminders, scores payment risk, applies cash Beam describes an agent that runs reminder sequences, risk scoring and cash application matching
AI features inside a finance platform Cash application, risk scoring, forecasting and drafting inside a broader suite Ramp's guide describes AI cash application with ambiguous matches routed to staff

Two things vary far more than the marketing suggests: how much the AI is allowed to do without a person, and what happens to your customers' data. Of the five vendor pages we read, Recovr's names specific actions that require approval, and Ramp's guide says AI-drafted messages are reviewed before sending; none of the five mentioned the EU AI Act. Several published performance figures (accuracy or days-sales-outstanding reductions) without methodology. That does not mean the products are poor, only that the pages do not let a buyer verify the claims.

What is the status of the DIGITAL EUR copilot?

Item Status
AI assistant you can use Not available. There is nothing to try, buy or join.
Research into what an assistant should and should not do RESEARCH (this page)
AI in matching decisions Not planned. Matching stays rule-based.
AI wording help for reminder drafts PLANNED as part of collections, propose-only, with approval before anything is sent
Rule-based matching, human approval, audit log DEMO in the Reconciliation Lab

Our product plan lists "AI assisted parsing and explanations" as a later item, after accounts, stored data and camt.053 import. We publish this page now because the design constraints should be settled before any code is written, and because buyers deserve a clear account of what we will not build.

Why does matching stay rule-based?

Matching a payment to an invoice is a decision with money attached. We want the same input to give the same output, and every suggestion to be explainable from facts you can check. A rule engine does that; a language model, by design, does not guarantee it.

Property DIGITAL EUR rule engine Language-model matching
Same files, same result Yes, every time Not guaranteed; output can vary between runs and model versions
Explanation Fixed reason codes: INVOICE_REFERENCE +65, EXACT_AMOUNT +20, COUNTERPARTY_IBAN +10, COUNTERPARTY_NAME +5, POSSIBLE_PARTIAL_PAYMENT −15, AMOUNT_EXCEEDS_OUTSTANDING −25 A generated text that may not reflect how the result was produced
Arithmetic Integer cents, allocations capped at invoice and payment Numbers handled as text unless separate code checks them
Amount-only matches Never suggested Possible if the model finds them "likely"
Testing The rules are covered by automated tests Requires statistical evaluation on representative data
Data leaving your device None in the demo Usually sent to a model provider

This is not a claim that AI is useless in receivables. Reading messy remittance text or a customer's email is exactly where language models are strong. The question is where to put the boundary: in our design, AI may help a person understand and write, while rules and people decide.

What could an assistant usefully do?

These are the research candidates we are examining. All are RESEARCH; none is built.

Task What the AI would produce What stays with rules or a person
Explain a suggestion in plain language A sentence built only from the reason codes and amounts of that suggestion The score, the reasons and the approval
Summarise the unresolved list A grouped overview, for example "three debits that look like bank fees, two credits with no reference" Every allocation; debits are never matched to invoices
Propose data fixes "This payer's IBAN appears on four paid invoices; consider storing it on the customer record" Whether to change the record
Draft reminder wording A polite, accurate draft using invoice number, open amount and reference Who is contacted, when, and whether anything is sent
Answer questions about approved data "Which invoices for this customer are partially allocated?" The underlying figures, which come from the database, not the model
Read a remittance advice email Candidate invoice references extracted from the text Matching, which uses the same rules as any other reference

Each candidate shares one property: the assistant's output is a proposal shown next to its source data. If the model is unavailable or wrong, the product still works, because nothing depends on it.

What would the assistant never do?

  • Approve, allocate or reverse a payment.
  • Send an email, letter or message.
  • Change matching rules or weights.
  • Assess a customer's creditworthiness or produce a credit score.
  • Hold, move or initiate payments, or connect to a bank.
  • Send personal or bank data to an AI provider without a documented agreement, minimisation and consent, as stated on our security page.
  • Use one customer's data to improve answers for another customer.

How does the EU AI Act apply to an AR assistant?

This section is a factual summary of official sources, not legal advice; the author is not a lawyer. How the Act applies depends on the actual function of a system, which we would assess before release.

The basics. The Artificial Intelligence Act is Regulation (EU) 2024/1689. According to the European Commission, it entered into force on 1 August 2024; the prohibited practices and AI-literacy provisions applied from 2 February 2025; obligations for general-purpose AI models applied from 2 August 2025; and the Act became generally applicable on 2 August 2026, with exceptions.

The AI Omnibus changed the timetable. The Commission's page, last updated 19 October 2026, states that the AI Omnibus amending regulation entered into force on 27 July 2026. It moved the strict obligations for high-risk use cases listed in Annex III to 2 December 2027, and for high-risk AI embedded in regulated products to 2 August 2028. Earlier articles that give 2 August 2026 for Annex III systems are out of date.

When could a receivables tool be high-risk? Annex III, point 5(b), lists AI systems intended to evaluate the creditworthiness of natural persons or establish their credit score, with an exception for systems used to detect financial fraud. Two consequences follow for receivables:

  • Many AR customers are companies, but freelancers and sole traders are natural persons. A feature that scores their likelihood of paying, or decides their credit terms, could fall within point 5(b).
  • Article 6(3) says an Annex III system is not considered high-risk in some cases, for example where it performs a narrow procedural task or a preparatory task, unless it profiles natural persons, in which case it is always high-risk.

Our design avoids credit scoring entirely. An assistant that rewrites a reason code into a sentence, or drafts a reminder that a person edits, is a much narrower function. We would still document the assessment rather than assume the outcome.

Transparency. Article 50(1) requires providers to design AI systems that interact directly with people so that those people are informed they are dealing with AI, unless that is obvious from the context. Any assistant we build would be labelled as AI wherever it appears, and AI-drafted text would be marked as a draft.

AI literacy. Article 4, as now amended, asks providers and deployers to take measures to support the development of AI literacy among the people who operate their AI systems. For a finance team, that means knowing what the assistant can get wrong.

Human oversight as a design principle. Article 14 applies to high-risk systems. It requires that people can oversee the system, stay aware of the tendency to over-rely on its output (automation bias), and disregard, override or reverse the output. We intend to adopt these principles even where the law would not require them, because they describe good practice for anything that touches money.

What does GDPR add?

The General Data Protection Regulation already applies to receivables data, with or without AI. Article 22 gives people the right not to be subject to a decision based solely on automated processing, including profiling, that produces legal effects or similarly significantly affects them. Chasing an individual for a debt, or changing their payment terms, can affect them significantly. Keeping a person in charge of each decision, and not using the assistant for such decisions at all, is the simplest way to stay clear of that line.

GDPR also requires data minimisation and a lawful basis for each processing purpose. In practice, an assistant should receive the least data needed for the task. Explaining a suggestion needs reason codes and amounts, not the customer's IBAN or full name.

How would human oversight work in practice?

A human-in-the-loop design is only meaningful if the human can actually disagree. Our research design sets these requirements:

  1. Evidence first, AI second. The rule-based evidence (reason codes, amounts, references) is always shown; the AI text appears beside it, never instead of it.
  2. No pre-selected decisions. The assistant never pre-selects "approve", so a click is a deliberate choice rather than an acceptance of a default.
  3. Quotable sources. Every factual statement in an AI answer must point to a record, such as an invoice or a bank line, so a reviewer can check it in one step.
  4. Visible uncertainty. When the assistant cannot answer from the data, it says so instead of guessing.
  5. Full logging. AI proposals and the human decision that followed are both written to the audit log, so an accountant can see what was suggested and what was done.
  6. Off by default. Customers would opt in to AI features, and could switch them off without losing any other function.
  7. Evaluation before release. Explanations would be tested against the rule engine's own output: an explanation that mentions evidence the engine did not find is a failure.

An illustration: one suggestion, two explanations

The suggestion below comes from the current rule engine (worked example on our SEPA invoice matching page): a €720.00 credit from Bauer Logistik GmbH, whose RF reference was mistyped, suggested for invoice INV-2026-0202 with a score of 35 and the reasons EXACT_AMOUNT, COUNTERPARTY_IBAN and COUNTERPARTY_NAME.

Rule-based explanation (exists today, as reason codes): EXACT_AMOUNT +20, COUNTERPARTY_IBAN +10, COUNTERPARTY_NAME +5 = 35. No INVOICE_REFERENCE.

What an assistant might add (illustrative only, not a product output): "This payment matches the invoice amount, and it came from the IBAN and company name stored for this customer. The payment text does not contain the invoice's reference, so the match rests on who paid and how much. Check whether the customer has another open invoice for the same amount before approving."

The second version is easier to read, but every statement in it must be traceable to the first. If the assistant had written "the reference matches", the explanation would be wrong, and the evaluation in step 7 above would reject it. That is the standard we would hold any AI feature to.

How should you evaluate any AI accounts receivable assistant?

Whether you look at our research or a product you can buy today, these questions separate useful AI from risky AI:

Question Why it matters
Which actions can the AI take without a person? Sending, posting and changing terms have consequences that are hard to undo
Can I see the evidence behind each AI suggestion? Unexplained output cannot be checked or audited
Is any customer scored for creditworthiness? Scoring natural persons may be a high-risk use under Annex III of the AI Act
Where is my data processed, and is it used for training? Customer and bank data are personal data under GDPR
How is the AI labelled to my team and my customers? Article 50 sets transparency duties for AI that interacts with people
How were the published accuracy figures measured? A percentage without method, sample and period cannot be compared
What happens when the AI is unavailable? Core receivables work should not stop
Is every AI proposal and human decision logged? Your accountant and auditor will ask

What can you use today instead?

If you came here looking for help with receivables now, these parts exist and work without AI:

  • Explained matching. The bank transfer reconciliation software page describes the rule engine, and the Reconciliation Lab lets you run it on synthetic or anonymised files in your browser.
  • A clear manual method. The SEPA reconciliation guide walks through matching SEPA transfers by hand, with checks for partial payments, duplicates and missing references.
  • Honest pricing information. The pricing page shows illustrative pre-launch prices (Solo €19, Growth €49, Agency €129 per month, before tax); nothing can be bought yet, and no AI feature is included in any plan.

What is still unknown?

  • Whether we will build an assistant at all depends on customer interviews and on whether the propose-only design is worth its cost.
  • Which model provider, hosting location and contract terms would be used is undecided.
  • How the European Commission's guidelines on high-risk classification will treat narrow receivables features is for official guidance to settle, not for us to assume.

Frequently asked questions

Can I use the DIGITAL EUR AI copilot today?

No. It is a research topic and is not available. The matching demo you can try uses fixed rules, not AI.

Does DIGITAL EUR use AI to match payments?

No. Matching uses published rules with fixed weights and integer-cent arithmetic. The same files always produce the same suggestions.

Would an AI assistant send payment reminders?

No. Any AI help would draft wording only. A person would decide whether and when to send, as described for collections.

Is an AI accounts receivable assistant high-risk under the EU AI Act?

It depends on what it does. Evaluating the creditworthiness of natural persons is listed as high-risk in Annex III; drafting text or explaining a rule-based match is a different function. The Annex III obligations apply from 2 December 2027, according to the Commission.

Would my data be sent to an AI provider?

Not without a documented agreement, data minimisation and your consent. Nothing in today's demo leaves your browser.

Will AI ever approve matches automatically?

No. Every allocation is approved by a named person, including matches with a perfect rule score.

Sources