Solution

Supplier approval and contract software for a buying group

A 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.

~50

approved suppliers managed on a platform we delivered

One source

the agreement and its amendments feed the rebate engine, with no re-keying

Fixed price

scope and price committed, migration of live agreements included

Supplier approval is the only process in a buying group that produces both legal commitments and numbers. A committee decision binds the organisation; the pricing annex attached to it drives hundreds of thousands of euros of rebates. Those two halves are almost always handled by different tools, and that is precisely where the cycle breaks.

An annual cycle nobody steers end to end

From a distance, approving a supplier looks like a binary decision. Up close it is a cycle with dated stages, different people at each stage, and a contractual document that changes version several times a year. Most central buying bodies run the first half of that cycle properly — application, assessment, committee — then abandon the second half in a shared folder.

  1. Supplier application

    A supplier applies, or a member proposes one. The file gathers identity, geographic coverage, product range, references and the entry terms being sought.

  2. Assessment

    Purchasing qualifies the file: overlap with suppliers already approved on the same family, financial standing, logistics capability, views of the members who would specify them.

  3. Approval committee

    The committee decides on the evidence. Its ruling stays attached to the file: approved, refused, approved subject to conditions, or deferred by one financial year.

  4. Framework agreement

    The contract sets the term, the product families in scope, logistics obligations, termination conditions and the rebate mechanics chosen.

  5. Negotiated terms and annual edition

    Scales, price grids, on-invoice discounts, year-end rebates: the layer that moves every year and must be dated as its own edition, never overwritten.

  6. Renewal or de-listing

    At expiry: automatic rollover, renegotiation, or exit. A de-listing keeps the history — rebates for the current year are still owed.

What actually breaks: the amendment signed in March

Teams rarely argue with that cycle; it matches what they already do. So the missing piece is not the process, it is the link between what was signed and what is applied. Four failure points come up almost every time.

  • The mid-year amendment goes nowhere. An extra discount point is won in March, the deal is signed as a PDF, and the calculation keeps running on January's scale.
  • Terms live in email. The scale actually applied is the one in a thread, not the one in the contractual annex — and the two have diverged without anyone deciding it.
  • The contract is not the reference for the calculation. Scales are retyped by hand into the campaign workbook, with the error margin that re-keying always carries.
  • Nobody sees the expiry dates. Renewals happen by default rollover, for want of a schedule visible more than a fortnight ahead.

None of these shows up day to day. They all surface at the same moment — the annual close — when a supplier produces an amendment the group never applied, or a member discovers they have bought all year on an expired scale.

The contract has to be the source of truth for the calculation

One sentence structures every platform we build on this scope: a commercial condition is data, not an attachment. The signed PDF stays, because it is what holds legally, but it stops being the only form in which the condition exists. The scale is captured, dated, versioned and attached to the agreement that carries it — and that is the data the rebate engine reads.

Filed supplier folderLive contract register
Negotiated termsA PDF annex, retyped by hand into the campaign workbookStructured scales, attached to the agreement, read directly by the engine
Mid-year amendmentSigned, filed, applied if somebody remembersA new dated version of the scale, effective from its own start date
Annual editionLast year's file is overwritten or duplicatedEvery financial year keeps its own terms, readable years later
Expiry datesA reminder in somebody's personal calendarContract schedule, renewal alerts, files waiting to be assessed
Committee decisionMinutes in a shared folderDecision attached to the supplier file, with its date, reason and evidence
De-listingThe supplier vanishes from the lists mid-yearDated exit, history preserved, current-year rebates settled
The difference is not where contracts are stored: it is whether the signed condition can be consumed by a calculation.

What the register has to model

A generic contract management tool stores a document and an expiry date. It models the following badly — and the following is most of what a network head office actually does.

Approval scope

Product families, brands, territories: a supplier is rarely approved across their whole catalogue, and that scope determines the rebate base.

Annual editions of terms

A multi-year framework agreement and an annual pricing annex do not share a lifetime. Treating them as one object forces you to renegotiate everything or freeze everything.

Amendments and effective dates

An amendment signed on 12 March backdated to 1 January is not the same event as one effective on signature. Both exist, and the calculation depends on the difference.

Members covered

Some terms apply to part of the network only: new joiners, one region, or the members who signed up to a specific commercial campaign.

Mutual commitments

Minimum volumes, exclusivity, delivery lead times, catalogue participation: the supplier's obligations as much as the group's, with the follow-up they require.

Traceable decisions

Who assessed, who voted, on what evidence. An approval committee issues a binding decision; it deserves better than mislaid minutes.

How we deliver it, and what it costs

MEKANO is a Lyon-based development studio building the management software of buying groups and member networks. We work at a fixed price, in two-week batches, and the source code is handed over. Supplier approval is rarely the first thing a group asks for — the rebate calculation hurts first — but it is almost always what makes that calculation trustworthy.

  1. Scoping: two workshops to map the real cycle, including the stages that exist only in the purchasing team's heads, and the exact shape of your negotiated terms.
  2. Prototype: the contract register on a sample of ten to fifteen suppliers, loaded with your real agreements, delivered in three weeks.
  3. Migration: live framework agreements, the current year's pricing annexes and every amendment still in force. This is the longest batch, and it is priced inside the fixed fee.
  4. Wiring into the calculation: the register's scales become the single source for the rebate engine, verified by replaying a past financial year.
  5. First renewal wave: the next round of expiries is run through the tool with us alongside, before you take it over on your own.

An entry point on this scope — scoping, working prototype, real contracts loaded — sits between €6,000 and €10,000 excluding VAT. That is not the price of the full platform: it is the price of knowing what the full platform has to do, with something usable if you decide to stop there.

Frequently asked questions

Should we start with supplier approval or with the rebate engine?
Usually the engine, because that is the measurable pain and the result shows in the first campaign. But an engine fed by hand-typed scales stays fragile: it computes correctly on wrong data. Supplier approval is therefore the batch that consolidates the previous one. When both are in the same project, we deliver the calculation first, the contract register second, and wire them together in the following batch.
Can existing agreements be migrated?
Yes, and it is a batch in its own right. We always migrate live framework agreements, the current year's pricing annexes and every amendment still in force. Earlier editions come across when they earn their keep — typically to replay a past year-end statement or handle a dispute. Capturing the scales is the expensive part; it is priced during scoping, not billed as an extra once the project has started.
Do you handle electronic signature of contracts and amendments?
We do not build a signature component: we connect the one you already use, or an off-the-shelf service if you have none. What interests us is what happens after signature — that the signed document comes back and attaches itself to the supplier file with its effective date, and that the associated scale becomes applicable without anyone touching it.
Do suppliers have to log in to the platform?
Not in the first batch, and many groups start without it. A supplier area earns its place when you want them to submit their own application file, their administrative documents and their invoiced-revenue returns. Each supplier then sees their own perimeter only: their agreements, their terms, their expiry dates. Never anyone else's, and never member-by-member detail outside their own scope.
How long does this batch take to go live?
Allow three weeks for scoping and the prototype, then six to ten weeks to production including migration of live agreements, on a scope of around fifty suppliers. What stretches the schedule is almost never development: it is the time needed to find the authoritative version of certain contracts, and to settle the cases where the signed annex and actual practice have drifted apart.

Let's talk about your situation

Thirty minutes, no commitment. You leave with a straight answer on feasibility, a budget order of magnitude and the next steps.

Book the call