Track every euro invoice in one place

Short answer

Invoice payment tracking software tells you, for each invoice, how much has been received, what is still open and which bank payment settled it. DIGITAL EUR derives that status only from bank credits a person has approved against an invoice. Today this runs in the free in-browser Reconciliation Lab; saved history, due dates and ageing are planned for the hosted product.

What problem does invoice payment tracking software solve?

Most small businesses already know which invoices they sent. The hard part is knowing which ones have really been paid, and by which transfer. A customer pays €1,500 against a €3,000 invoice. Another pays two invoices with one transfer. A third pays the right amount but forgets the invoice number. A payment provider sends a batch payout that contains several customers at once. If your tracking tool simply lets someone click "paid", each of these cases is a judgement call that leaves no evidence behind.

Invoice payment tracking software should close that gap. It should answer four questions without anyone opening the bank portal:

1. Which bank credit was applied to this invoice, and for how much?
2. What amount is still outstanding after every approved payment?
3. Who decided that the payment belonged to this invoice, and when?
4. Which incoming credits are not yet explained by any invoice?

Many invoicing tools answer the first two questions for card or wallet payments, because the payment provider tells the tool which invoice was paid. Bank transfers carry no such link. The only connection between a SEPA credit transfer and your invoice is the remittance text, the payer's IBAN and the payer's name. DIGITAL EUR is built around that reality: status is a consequence of matching, not a separate field someone edits.

Who is it for, and who should look elsewhere?

It is designed for businesses that invoice in euro and are paid mainly by bank transfer:

• freelancers and small companies that track payments in a spreadsheet today;
• agencies and consultancies with retainers, deposits and instalments, where partial payments are normal;
• bookkeepers who receive a client's open-invoice list and bank statement every month and need to show what was matched;
• businesses selling across the euro area that want one consistent way to see what each customer still owes.

Look elsewhere if you need card acquiring, payment links, automatic posting to a general ledger, multi-currency invoices, or a live connection to your bank. None of these is offered today, and some (taking payments, reading bank accounts on your behalf) would require licensed partners. Our security page explains what we do and do not do with data.

What works today, and what is planned?

The capability on this page is planned for the hosted product. A working subset is available now in the browser demo. The table separates the two so you can judge what you can test.

You can try the available parts in the Reconciliation Lab with the built-in sample data or your own anonymised files.

How is an invoice's status derived?

Status is calculated, never typed. For every invoice the software adds up the allocations a person has approved and compares the sum with the amount due:

• allocated = the sum of all approved allocations to that invoice;
• outstanding = amount due − allocated;
• no allocation means the invoice is open; an allocation below the amount due means it is partially allocated; an allocation equal to the amount due means it is fully allocated.

Three rules keep these numbers honest.

An allocation can never exceed what is left. When you approve a suggestion, the amount applied is the smaller of the invoice's outstanding amount and the transaction's unused amount. If you type a specific amount, it is rejected if it would push the invoice above its total or use more money than the transaction still has. An invoice therefore cannot become "more than paid" by accident, and one transfer cannot be spent twice.

Rejecting undoes the money, not the history. If you reject a suggestion you had approved, its allocation is released and the invoice's outstanding amount goes back up. The audit log keeps both the original approval and the reversal; earlier entries are never edited or removed.

Suggestions need evidence, not coincidence. A bank credit becomes a candidate for an invoice only if the invoice reference appears in the remittance text, or the payer's IBAN matches the customer IBAN, or the payer's name matches the customer name. An equal amount on its own never creates a suggestion. The weights are fixed and published on the reconciliation product page: invoice reference +65, exact amount +20, counterparty IBAN +10, counterparty name +5, possible partial payment −15, amount exceeds outstanding −25. When two invoices tie for the top score, both are marked ambiguous and a person chooses.

The score is a transparent sum, not a probability. A score of 100 still needs approval.

Worked example: three invoices, four bank credits

The following example is synthetic. We ran it through the same matching and decision code the Lab uses, so the scores and statuses below are its actual output.

Open invoices (input)

Bank credits (input, all EUR, all incoming)

Suggestions (output)

Two details are worth noticing. The names match although the bank wrote "S.R.L." and "S.L." with dots and capitals, because names are compared after removing punctuation and spacing. And T4, a payout with the same amount as an open invoice, produces no suggestion at all. It stays in the unresolved list until someone explains it.

Status after a reviewer approves the three suggestions

The remaining €1,500 on INV-2026-042 is still visible, and T4 is still unexplained. Those two lines are exactly what a person should look at next.

How should partial invoice payments be tracked?

Partial invoice payment tracking is where spreadsheets and "mark as paid" buttons fail most often. A partial payment can mean an agreed instalment, a deposit, a short payment after a deduction, a payment for some line items only, or a mistake. Recording it well means keeping three things together: the transaction that paid, the amount applied, and the balance left.

In DIGITAL EUR a partial payment is handled like this:

1. The credit is smaller than the invoice amount, so the suggestion carries the reason "possible partial payment" and loses 15 points. The deduction is a prompt to look, not a penalty for the customer.
2. When you approve, the allocation equals the credit amount (or less, if you choose), and the invoice becomes partially allocated with the remainder shown.
3. A later credit for the same invoice receives its own suggestion. Approving it reduces the outstanding amount again, never below zero.
4. Each step is a separate audit entry with the reviewer's name and time, so you can show later how a €3,000 invoice was settled by two transfers.

Before you treat a short payment as an instalment, ask why it is short. Common reasons include a disputed line item, a withholding the customer believes it may apply, a deposit already paid by another route, or an outgoing bank charge on a non-SEPA route. Each has a different follow-up. The planned collections workflow uses the outstanding amount from approved allocations, so a reminder can state the correct remaining balance instead of the full invoice amount.

What happens with overpayments and duplicate payments?

Suppose a customer transfers €1,300 against a €1,200 invoice, with the correct reference. The suggestion shows "amount exceeds outstanding" and loses 25 points. If you approve it, the allocation is capped at €1,200: the invoice becomes fully allocated and €100 remains unused on the transaction. The surplus is not silently absorbed and not silently lost; it stays visible as part of a transaction that is not fully used.

The same rule protects you from duplicates. If a customer pays the same invoice twice, the second payment cannot be approved against an invoice that is already fully allocated; the Lab refuses with a clear message. Deciding whether to refund, keep as credit or apply to another invoice is an accounting decision that stays with you.

In the hosted product we plan an explicit overpaid flag and a list of unused transaction amounts, so surpluses can be reviewed on their own screen. Until then, the demo shows them through the capped allocation.

Which SEPA invoice reference format works best?

Tracking is only as reliable as the reference the customer sends. Two formats work well with SEPA credit transfers:

• Your own invoice number in the unstructured remittance field. The European Payments Council implementation guidelines allow 1 to 140 characters there.
• A structured creditor reference in the ISO 11649 "RF" format: the letters RF, two check digits calculated like an IBAN check, and up to 21 letters or digits chosen by you. It is usually printed in groups of four, as in RF18 5390 0754 7034. Under the EPC guidelines, the structured block may be used once per payment and its content may not exceed 140 characters; when an RF reference is used, the issuer is given as "ISO".

The same EPC guidelines say the receiving bank is not required to validate the check digits of a creditor reference. Do not assume your bank will reject a mistyped RF reference: your own matching must cope with it.

Practical rules that follow from how our matcher reads references:

• Make the reference at least four letters or digits long. Shorter references are ignored, because they match too much by chance.
• Use unique, whole tokens. The matcher compares complete tokens, so INV-12 never matches INV-123.
• Store the reference the way you print it. If your invoice file holds "RF18 5390 0754 7034" with spaces, a payer who types "RF18539007547034" still matches. If your file holds the compact form, a payer who types the spaced form does not. Separators in the stored reference allow any separator, or none, in the payment.
• Print the reference next to the IBAN, not in small print, and ask customers paying several invoices to list every number.

For the full process of preparing references and statements, read the SEPA reconciliation guide.

Does it work for invoice payment tracking across Europe?

For European B2B invoice payments in euro, yes, within clear limits. The matcher compares only invoices and credits in the same currency, so a euro invoice is matched only with euro credits. It reads incoming credits only; debits are ignored. It does not convert currencies and it does not treat a non-euro credit as a partial payment of a euro invoice.

Cross-border invoicing in the EU raises questions this page does not answer: VAT treatment, e-invoicing obligations and language requirements differ by country and change over time. DIGITAL EUR does not create or validate invoices, so it does not decide any of those questions for you. What it does is the same in every euro country: match the bank credit to the invoice on evidence, and keep the decision on record. If you need to estimate what a payment route costs before choosing it, the euro payment fee calculator explains its method.

Is this euro invoicing software or an invoice generator?

No. DIGITAL EUR is not euro invoicing software in the sense of creating invoices, and it is not a euro invoice generator. You keep issuing invoices in the tool you use today, whether that is accounting software, an invoice generator in euro or a word processor, and export the open invoices as a CSV file.

Likewise, it is not recurring invoice software and it does not create invoice payment links. Payment links in Europe are provided by payment service providers that hold the relevant authorisations; accepting payments through them would mean integrating a licensed provider, which we have not done. If you already use payment links, the money still reaches your bank account, often as a combined payout. That payout is exactly the kind of credit our matcher will not assign on amount alone, which is the safer behaviour.

This narrow scope is deliberate. Tracking is more trustworthy when the tool that records "paid" is not also the tool that wants the invoice to look paid.

What should an invoice status dashboard show?

A useful invoice status dashboard answers "who owes what, and how sure are we?" at a glance. Based on the gaps we saw in existing tools, the hosted product is planned to show, per invoice:

The ageing view, grouped by days overdue, belongs to the collections side of the product, because it drives who is contacted and when. See collections for how follow-ups are planned.

How does this compare with a spreadsheet or accounting software?

The comparison below uses our own criteria. It describes typical approaches, not named products, and makes no claims about any vendor's prices.

If your invoicing tool already receives a reliable payment signal for every invoice, you may not need us. The case for DIGITAL EUR is strongest where most money arrives by bank transfer and the link between transfer and invoice has to be established and documented.

What does your accountant receive?

An accountant invoice export should be evidence, not just a list of paid invoices. The Lab exports approved allocations as a CSV file with these columns: invoice_id, transaction_id, amount, currency, approved_by, approved_at and a note. Every row says it is a demo export, not an accounting entry, and that no payment was made.

Two details matter for accountants. First, cells that a spreadsheet could interpret as a formula are written with a leading apostrophe, which protects against CSV injection, a risk documented by OWASP. Second, amounts use a dot as the decimal separator and no thousands separator, which avoids the common comma-and-dot confusion between European locales. The file opens in any spreadsheet and can be imported into most accounting tools as a list of receipts to post.

Privacy, security and review controls

In the demo, files are read and processed in your browser. They are not uploaded to our servers and nothing is kept when you close the page. That is why the demo cannot save history.

For the hosted product we plan accounts with per-organisation separation, an access log and deletion on request. We will not ask for bank logins and we will not read bank accounts directly. We do not claim certifications we do not have. The current position is on the security page and in the privacy notice.

How to try invoice tracking in the demo

1. Open the Reconciliation Lab and load the sample data, or prepare two anonymised CSV files.
2. Your invoice file needs the columns invoice_id, customer_name, currency, amount_due and reference; customer_iban is optional.
3. Your transaction file needs transaction_id, currency, amount, remittance and direction (CRDT for incoming); counterparty name and IBAN are optional but improve suggestions.
4. Run matching and read the reasons on each suggestion before deciding.
5. Enter your name, approve or reject, and watch each invoice's allocated and outstanding amounts change.
6. Export the approved allocations and compare them with your current records.

Pricing and availability

Accounts are not open and nothing can be bought. The pricing page shows illustrative pre-launch test prices of €19, €49 and €129 per month for the Solo, Growth and Agency plans, excluding VAT. Invoice status tracking is listed from the Solo plan upwards. There is no checkout, and prices may change after customer interviews.

Honest limitations

• Tracking is planned; only the in-browser subset described above works today.
• The demo has no due dates, so it cannot say how overdue an invoice is.
• Nothing is saved between sessions.
• Only euro-style CSV files are accepted: comma-separated, dot decimals, one currency per row.
• Ambiguous payments are flagged, not resolved; a person decides.
• One transfer paying several invoices needs one approval per invoice, and works only where each invoice has evidence in the payment.
• The software never moves money, never confirms a payment to anyone and never posts to your ledger.

Frequently asked questions

Can I mark an invoice as paid manually?

Not in the current demo. Status comes only from approved allocations of real bank credits. A manual "paid" switch would reintroduce the problem the product is meant to solve. How cash payments, offsets and credit notes will be recorded in the hosted product is still being designed; whatever the method, it will need a reason and an audit entry.

Does DIGITAL EUR connect to my bank?

No. You export a statement from your bank and import it as a file. camt.053 import is planned; direct bank connections are not offered.

How are payments for several invoices at once handled?

Each invoice whose reference appears in the remittance receives its own suggestion from the same transaction; if their scores tie, they are marked ambiguous so that you look before approving. You approve them one by one, and each allocation reduces the transaction's unused amount, so the transfer can never be spent beyond its total.

What happens if a customer pays without any reference?

If the payer's IBAN or name matches the customer, you still get a suggestion with a lower score and visible reasons. If nothing matches, the credit stays in the unresolved list for a person to investigate.

Is the score a probability?

No. It is a fixed sum of named rule weights, shown so that you can see why a pair was suggested. Every suggestion, including a score of 100, requires approval.

Can I use real customer data in the demo?

The demo runs in your browser and does not upload files, but it is a demonstration. We recommend anonymised or sample data until the hosted product, its terms and its data processing agreement are available.

Will invoice tracking include reminders?

Reminders are a separate, planned capability. They will be drafted from approved status and sent only after a person approves each message. See collections.

Sources

• European Payments Council, SEPA Credit Transfer Scheme Inter-PSP Implementation Guidelines 2025 version 1.0, EPC115-06 (PDF) (accessed 5 November 2026)
• Finance Finland, Structure of the RF creditor reference (ISO 11649) (PDF) (accessed 5 November 2026)
• OWASP, CSV Injection (accessed 5 November 2026)
• QuickBooks Help, Track the status of invoices — example of common invoice status vocabulary (accessed 5 November 2026)