For accounting
Amount, supplier, date, reference of the programme and of the budget allocated. The line is found without manual reconstruction, payment by payment.
How it works
Every payment found, with its status and the rule that allowed it.
Every payment is recorded on a tamper-proof blockchain, with its amount, its supplier, its date and the rule applied. Your teams find the operation and its status in real time, each of them in the view that is theirs.
- A payment of 120,00 € is made at a referenced supplier, on 12/10/2026 at 12:04.
- The payment is sealed: it becomes block 145, carrying the fingerprint 4f2a…c19b.
- The block joins a chain of five blocks, where every block locks the one before.
- Changing the amount to 480,00 € breaks the seal and the link: the chain rejects the change, then the original record is restored.
Scope of the proof
Proof that cannot be rewritten, and exactly what it covers.
Every accepted payment becomes a sealed entry in a chained ledger. Each entry locks the previous one: changing an amount breaks the link, and the ledger refuses the change.
What the proof shows ✓The amount paid✓The supplier paid✓The date and time✓The rule applied
What it does not show ×The contents of the basket×The delivery of the good×The use made after the purchase×Any personal data
- Entry142 312,00 € sealed
- Entry143 80,00 € sealed
- Entry144 45,00 € sealed
- Entry145 120,00 € sealed
- Entry146 600,00 € sealed
Each entry locks the previous one. Entry 145 carries the fingerprint 4f2a…c19b.
Changing 120,00 € to 480,00 € breaks the link Change refused
Events tracked
What a programme records, from the first euro to redemption
Every event is time-stamped and linked to the programme. Nothing is reconstructed after the fact.
- Contribution of funds
- A transfer, a donation, a contribution to a fundraising pot or a grant arrives in euros, linked to the programme it finances.
- Issuance
- The matching earmarkable digital euro is issued, one for one, and allocated to the programme.
- Enrolment and activation
- A beneficiary joins the programme. Their account and their card are activated.
- Allocation of a budget
- An amount is allocated to them, with the rules that frame it.
- Control before execution
- The applicable rule is checked and anomalies are detected, before the operation goes through.
- Authorisation or refusal
- The operation is authorised, or refused with its reason.
- Settlement
- The supplier is paid. The payment is recorded on the blockchain.
- Redemption
- A sum returns to the programme or to the funder, under the conditions of the contract.
- Change to a rule
- A ceiling, a period, a list of suppliers or an area changes, on the date the change takes effect.
Views by role
Each party finds what is theirs
Transparency is not putting everything in common. Each role has a view defined by its responsibility and its purpose.
| Role | What they find | What they do not see |
|---|---|---|
| Funder | The budget, its consumption in real time, every payment with its amount, its supplier, its date and the rule applied. | Individual files and the personal data of beneficiaries. |
| Contributor | The use of their contribution, payment by payment, in the programme they funded. | The other programmes, and the identity of beneficiaries. |
| The programme team | The settings, the budgets allocated, the requests, the payments and the reasons for refusal. | Anything belonging to another programme. |
| Beneficiary | Their balance, their payments, their statuses and the reason for a refusal concerning them. | The operations of other beneficiaries. |
| Supplier | The payments they have taken. | The programme’s rules and the beneficiaries’ budgets. |
Authorisation and settlement
An authorisation is not a settlement
These are two distinct events, at two distinct moments. Confusing them gives two false readings of the same budget.
| Status | What it means | Effect on the budget |
|---|---|---|
| Authorised | The rule was checked before execution and the operation went through. | The amount is reserved against the available budget. |
| Settled | The supplier has been paid. It is that payment which is recorded on the blockchain. | The amount is charged to the budget used. |
| Refused | A programme rule was not satisfied. The reason is kept, and the beneficiary is given it. | No effect: the budget stays available. |
A budget is therefore read as three amounts: what is reserved, what is charged, what remains available. All three are visible in real time.
Reconciliation
Find the line, and the rule that allowed it
A recorded payment carries the information needed for accounting reconciliation and internal audit.
For internal audit
The rule applied at the time of the operation, its status and, in the event of a refusal, its reason. The audit bears on the rule, not on a declaration.
Exports
The format, the frequency, the role that receives them and the fields of the exports are defined with the teams that use them. Every export states what it covers and its extraction date. No universal export format is announced on this site.
Corrections
An entry is not rewritten, it is explained
Correcting does not mean altering the past, but explaining it.
An entry recorded on the blockchain is not modified: neither MAP nor the funder can rewrite it. A correction is recorded as a new event, linked to the original operation: cancellation, refund, adjustment. The history stays readable in both directions, from the correction to the original operation and from the operation to its corrections.
That is exactly what makes the trace useful: if it could be touched up, it would prove nothing.
No personal data on the chain
The entries recorded on the blockchain bear on the programme’s operations. The identity of beneficiaries and their personal data are kept off chain, with the retention periods and the access described in the compliance centre. See Personal data and Ledger and blockchain.
Request a demo
Let us look at what you have to be able to show.
Tell us what your organisation has to justify, to whom and by when.