We know how you work.
Annual supplier agreements, rebate tiers, year-end bonuses: we have already modelled and coded them. You will not have to explain what a year-end rebate is.
Supplier approval, revenue declarations, rebate and year-end bonus calculations, document management, member portal: we have already built all of it for a 60-company buying group. We can build it for yours — fitted to your rules, not the other way round.
Scoping + prototype in 3 weeks, deducted from the project.
Annual supplier agreements, rebate tiers, year-end bonuses: we have already modelled and coded them. You will not have to explain what a year-end rebate is.
We handle scoping, development, the acceptance environment, go-live and maintenance. Your contact is a project manager, not a ticket.
Source code handed over, documentation delivered, contractual reversibility. If we disappeared tomorrow, your tool keeps running.
A buying group runs processes no off-the-shelf software models properly: the annual approval of its suppliers, the collection of member revenue declarations, the calculation of year-end rebates, and the contractual memory of all of it. None of that is accounting, CRM or order management. Which is why it almost always ends up in spreadsheets.
The vendors addressing this market sell packaged products: a rebate module inside an ERP, a franchise extranet, a membership platform designed for associations. Each covers part of the need correctly and imposes its own way of working on the rest. In a buying group, that remainder is precisely what is specific: the structure of the negotiated scales, the split between the central body and its members, how a member who joined in March is treated at the annual close.
The outcome is always the same. The package goes in, it covers seventy per cent of the need, and the remaining thirty per cent goes back into Excel — now with an extra reconciliation step between the two. The group has added a tool without removing one.
The building blocks below make up the usual scope. No project delivers them all at once: they are sequenced, and the order depends far more on your annual calendar than on any technical logic.
Applications, review, approval committee, framework agreement and amendments, negotiated terms, annual vintage and renewal, de-listing. The agreement has to be the source of truth for the calculation, not a PDF filed next to it.
Declaration windows, entry or import, automatic reminders, reconciliation between the revenue declared by the member and the revenue invoiced by the supplier, adjudication of the gaps, period closing.
Tiered scales, multiple bases, conditional premiums, pro-rata, split between group and member, traceable adjustments, a locked and reproducible annual statement.
The authenticated space where members declare, retrieve their terms, follow their rebates and update their sites. It only stays alive if it carries a mandatory process.
Agreements, amendments, certificates, committee minutes. Storing is not the problem: answering "which agreements include a logistics discount?" without opening forty files is.
Per-supplier statements for negotiation, per-member statements, the general manager's dashboard, accounting exports — generated, dated and archived exactly as they were sent.
The comparison is not about speed. A well-built spreadsheet calculates quickly. What it does not do is remember — and in a buying group, memory is most of the work.
| Spreadsheets and inboxes | Dedicated platform | |
|---|---|---|
| Who owns the process | One or two people who know which files to open | The organisation: the process survives the person who ran it |
| Revenue declarations | Files received by email, inconsistent formats, manual chasing | Window opened, controlled entry or import, automatic reminders, visible response rate |
| Negotiated terms | In the signed agreement, retyped by hand into the calculation file | Captured once, attached to the agreement, applied as-is by the engine |
| Declared vs invoiced gaps | Found late, adjudicated from memory | Reconciled at close, each gap investigated and justified |
| Annual statement | A frozen workbook on a network share | Locked, timestamped, replayable identically years later |
| A member disputes a figure | Manual reconstruction, several days | Line-by-line breakdown, with the origin of every amount |
| A new scale rule | One more column, duplicated everywhere | A dated rule that applies from the date it came into force |
A buying group cannot stop while it rebuilds. Approval agreements renew on fixed dates, declaration windows open on fixed dates, the statement falls once a year. Sequencing is therefore not a methodological preference: it is a constraint your calendar imposes.
Two workshops with your teams to model the rules as they are actually applied — exceptions included. The deliverable is a signed-off rules document and a fixed price, before a line of code.
We start with the process whose pain is measurable and whose risk is low: usually document management or the portal, sometimes the rebate engine when that is what is burning.
Approval workflows start one cycle before renewal. Declarations go live at the beginning of a window, never in the middle. Two-week sprints, a demo at the end of each, formal acceptance at every milestone.
The first live campaign runs alongside your current method. You only switch once the two results reconcile — which is also where the rules nobody had written down surface.
For a group of fifty to eighty member companies, a full rebuild spans nine to fifteen months depending on how many annual cycles it has to cross. That is the same duration as a big-bang project, with value arriving from week eight instead of month eighteen, and risk spread across ten small go-lives instead of one large one.
We always start with scoping and a prototype at €6,000–10,000 excluding VAT depending on the scope, deducted in full from the project fee if it goes ahead. It is the only honest way to price: nobody can commit to a fixed price on a need that has not been written down yet.
Beyond that, a buying group platform is reasoned batch by batch, not as a blind headline fixed price. What moves the budget is almost never the size of the group: it is the number of unwritten rules to reconstruct, the state of the history to migrate, and the number of people who have to sign off a decision. A group with an available business owner empowered to decide costs structurally less than one where every arbitration waits for the next board meeting.
MEKANO is a development studio based in Lyon, France, led by its founder, who personally runs every project. We have already delivered the complete platform of a Lyon-based buying group of more than 60 member companies: member and supplier portal, approval workflows, revenue declaration module, rebate calculation engine and document management with search across agreements.
What we do not do: sell a licence, impose a data model, or promise that an existing package will cover your rules. If a market product answers your need, we will say so during the discovery call — it has happened, and it costs us less than a badly started project.
Every building block below runs in production. They ship one at a time, in whatever order matches your calendar — never all at once.
Year-end rebates are the most scrutinised calculation a buying group runs: every member checks their figure, every supplier contests theirs, and the annual statement has to survive an auditor. We build the engine that runs your actual scales — not a package that asks you to bend your rules to fit it.
Read moreA framework agreement signed in November decides the scales applied fourteen months later, on a base nobody has measured yet. Between signature and year-end close, the negotiated terms get lost: they live in a filed PDF, in an email thread, and in a workbook where someone retyped them by hand.
Read moreA member portal is judged on one number: how many members log in without being asked to. Most buying-group extranets plateau at a few dozen visits a year, because they were designed as a document showcase when members were looking for a service desk.
Read moreA buying group cannot compute a single rebate until it knows, period by period and supplier by supplier, what each member actually bought. That information arrives late, incomplete, in as many formats as there are members — and head office spends its quarters knocking it back into shape.
Read moreA buying group accumulates framework agreements, amendments, certificates, purchasing committee minutes and supporting documents by the thousand. Storing them was never the hard part. The day the managing director asks which agreements include a logistics discount, no network share can answer.
Read moreA buying group spends a remarkable amount of time rebuilding the same statements: the managing director's dashboard, the per-supplier summaries before annual negotiation, member statements, the board pack. Automating them saves days — provided the data underneath is consolidated and dated.
Read moreA management system does not die overnight. It slowly becomes impossible to change: the vendor has stopped answering, the developer who wrote it has left, the language version is out of support. At that point the question is no longer technical — it is which exit costs least.
Read moreA buying group does not rebuild its system because the software is old, but because a critical process has started to overflow: the rebate close, the collection of declarations, the renewal of supplier agreements. The project therefore has a real deadline, an annual calendar it cannot move, and fifteen years of data to migrate.
Read moreTwo organisations bearing the same label can have opposite software needs: in one, members buy direct and the central body negotiates; in the other, the central body buys and resells. That is where tool selection is decided, long before any feature discussion — and most organisations run both models at once.
Read moreNot every network head office negotiates purchasing terms. A trade federation, a union, an employers' group or a retail brand maintains a directory, calls subscriptions, manages mandates and collects data from its members. The mechanics resemble those of a buying group, but the objects and the deadlines are not the same.
Read moreA Lyon-based buying group of more than 60 member companies
This Lyon-based buying group brings together more than 60 member companies and around fifty approved suppliers in refrigeration, air conditioning and professional kitchen equipment. Its website and management application ran on a monolithic proprietary framework that had become a brake: membership applications, annual supplier agreements, revenue declarations, year-end rebate calculations, document management — all of it had to be rethought.
What MEKANO delivered
A complete platform, built in batches with formal acceptance at every milestone.
The terms
Full reference and client contact shared on request during the discovery call.
You leave the call with a straight answer on feasibility, a budget order of magnitude and clear next steps. Scoping + prototype in 3 weeks, deducted in full from the project if it goes ahead.