Several funders, one budget, and each of them sees what they paid for.
We have the solution. Funds come into the programme. MAP issues the matching electronic money: euros issued against the euros you pay in, one for one. Every contributor can then see what their contribution has paid for, within their access rights.
Three funders feed the same programme: a local authority pays in 40 000,00 €, a foundation 24 000,00 € and a company 16 000,00 €. Every amount in this animation is an example.
The three contributions join a single 80 000,00 € envelope, where each origin stays distinct: 50% for the local authority, 30% for the foundation, 20% for the company.
A payment of 1 200,00 € leaves the envelope for a referenced supplier, drawing on each origin pro rata.
Each funder sees what its contribution paid for in that payment: 600,00 € for the local authority, 360,00 € for the foundation, 240,00 € for the company.
Benefits
What this service changes for your teams.
One programme, several funders
A foundation, companies, a local authority or individuals fund the same envelope. The allocation rule is written before the first spend.
Reconciliation done in advance
Every payment received carries its reference and its allocation. Your teams find the origin of the funds without rebuilding a spreadsheet.
Account for the funds without opening everything
Each contributor sees what concerns them, according to the rights set with you when the programme is prepared. Beneficiaries’ data are not open to everyone.
Your rules
What we set with you, before the first contribution.
The core is the same for every programme. What varies from one programme to the next is set with your teams, before the first spend.
The collection methods
The methods opened to your collection, their reconciliation references and their timings.
Example: transfer, donation, corporate giving, fundraising pot
The allocation rule
The share of each contribution in the programme, written before the first spend.
Example: one programme, one written allocation rule
Each contributor’s rights
What each contributor may view, and what stays outside their view.
Example: one view per contributor, according to their rights
Failures, refunds and balances
The handling of failed payments, agreed refunds and balances left at the end of the programme.
Example: a failed payment, an agreed refund
Deliverables and how it works
What we put in place with you.
✓A contribution journey fitted to the programme and to its funders.
✓The allocation of the funds received, the tracking of their state and the reconciliation of the entries.
✓The tracking of contributions and the handling of agreed refunds.
✓Viewing rights by role: funder, programme team, contributor.
A clear framework
A precise framework, known before you sign.
The proof covers the payment: amount, supplier, date, rule applied. The rest is written here, so that nobody discovers it afterwards.
Collecting is not acquiring on behalf of others
Collecting funds does not mean that stand-alone card acquiring, recurring payments or marketplace collection are included in the programme.
The financial parties are identified first
The financial parties to the programme must be identified before it is set up.
No automatic tax receipt
Collection creates no automatic right to a tax receipt.
What we show before any commitment. Before any commitment, we show a payment received, its allocation, a failed payment, a refund and the view authorised for a contributor.
A worked example
A foundation, responsible for a co-funded equipment programme.
A foundation and three companies fund the same envelope. The team running the programme finds each contribution, the payments it financed and the state of the balance, according to the rights of each party.
Contributors (example)
4 funders
Envelope brought together (example)
€80,000.00
Allocation
one programme, one written allocation rule
What you see
one view per contributor, according to their rights
Proof
every payment recorded on a tamper-proof blockchain
Situation and values given as an example. No result and no price is announced.
Yes: donations, pots and corporate giving. Each contribution is linked to the programme it finances. Every contributor then sees the payments their contribution made possible. The allocation rule, viewing rights and the handling of remaining balances are settled from the first conversation.
No. Each role sees what concerns it, and nothing more. A funder follows the payments of its own programme in real time. It has access neither to beneficiaries’ personal data nor to their files.
100% of operations are checked before execution. A payment outside the rules is refused, and the reason is recorded. The beneficiary knows why straight away. Refunds and remaining balances follow the programme contract. An end date does not make the funds disappear.
An earmarked payment accepted, then a payment refused. What each role sees in both cases, and the record written to the blockchain. The demonstration draws on the Mes Potos solidarity programme, documented with what it covers, and is set around your own programme.
Tell us who funds the programme, who uses the funds and what it must allow people to pay for. We identify the rules, what you must be able to track and the points that need validation.
