Find every payment and its status.
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.
Events tracked
What a programme records
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 accounting
Amount, supplier, date, reference of the programme and of the budget allocated. The line is found without manual reconstruction, payment by payment.
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
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.
Scope of the proof
What the proof covers, and what it does not
The difference between a report produced by an operator and a proof lies in what can be said about it. So it is better to say precisely what it establishes.
What the proof covers
- The payment: its amount, its supplier, its date.
- The programme rule applied to that payment.
- The recording on a tamper-proof blockchain, which neither MAP nor the funder can alter.
- The full chain, from the contribution of funds to the settlement of the supplier.
What it does not cover
- The contents of the basket: item-by-item control requires an integration and suitable data.
- The delivery of the good or the service, and its use afterwards.
- Social or economic impact, which is assessed with a method, a population and a period.
- The truthfulness of a document provided by a third party.
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. A MAP expert answers you, with no commitment.