A management platform for purchasing centrals and referencing centrals

A management platform for a purchasing central contains different things depending on the business model it serves. If members buy direct from the supplier, the central body invoices no goods: it negotiates, checks declared volumes and redistributes back-end terms. If it buys in its own name and resells, it carries a catalogue, stock, customer invoicing and credit exposure. The two businesses share a supplier master file, and very little else.

Referencing central or purchasing central in the strict sense

The distinction is legal before it is technical, and nobody states it clearly at the point of choosing a tool. A referencing central negotiates terms on behalf of its members and is paid by the supplier; invoices flow from supplier to member without ever passing through it. A purchasing central in the strict sense buys, takes ownership of the goods and resells them: it carries stock risk and credit risk the first one does not.

That mix is the rule rather than the exception: a co-operative references most of its families and buys-and-resells the rest, often because a supplier refuses to invoice smaller members, or because an own-brand range has to pass through the central body. The classic trap is picking a package designed for only one of the two models. The other ends up in a parallel spreadsheet, recreating exactly the problem the platform was meant to remove.

The supplier relationship is the real master file

A member changes address once every five years. A supplier's terms change three times a year. So it is the supplier record, not the member record, that must be designed as a dated history rather than a current state.

Getting the volumes in

Nothing can be computed without volume, and volume is the most fragile data in the chain. Three sources coexist, with three different levels of trust.

• The member's declaration: quick to put in place, but always late and sometimes understated. It needs automatic reminders, a plausibility check against the previous period, and a clear status between declared, checked and approved.
• The supplier's statement: more reliable on amounts, but in its own format, its own product coding and its own calendar. Normalising thirty heterogeneous files is a task in its own right, not an import detail.
• The central body's own invoicing, for the buy-and-resell side: the only native source, and the only case where volume does not have to be requested from anyone.

Double accounting: the group and the member

Every amount has two readings. On the organisation's side: what the supplier owes, what has been invoiced, what has been collected. On the member's side: what is due for their contribution to volume, what is passed back, what is retained to fund operations. The two views must reconcile to the euro, and never reconcile on their own.

1. 1

   Consolidate the base

   Volumes reconciled by supplier, by family and by member across the agreement period — which is not always the financial year, and which shifts when an amendment takes effect mid-year.

2. 2

   Compute what the supplier owes

   Tiered scales and dated terms applied to the base, then an itemised statement issued to the supplier for agreement before invoicing. That statement is what prevents months of argument.

3. 3

   Invoice and track collection

   The rebate invoice is raised by the organisation. The lag between issue and collection is a purchasing central's main cash position, and has to be tracked as such.

4. 4

   Allocate to members

   Allocation key applied, the retained share isolated on its own line, credit note or transfer produced with the supporting breakdown attached.

5. 5

   Close and lock

   Campaign frozen, journal entries exported to accounting, detail retained so the close can be replayed during an audit or a later dispute.

Allocating the back margin without losing the autumn to it

Allocation is the political question of the organisation. The rules we meet almost always combine, and it is the combination that makes a spreadsheet untenable.

1. Pro rata to the volume each member declared with the supplier concerned: the default rule, and the easiest to defend at a general meeting.
2. With a share retained by the organisation, as a percentage or a flat amount, to fund its operations and services.
3. With a payment threshold: below a certain amount the rebate stays in the common pot rather than producing a twelve-euro credit note.
4. With pro-rata treatment for members joining or leaving mid-year, and for suppliers approved mid-campaign.
5. With rules by college, by seniority or by volume commitment, where the articles of association provide for them.

Taken one at a time these rules are simple. Applied to some fifty suppliers and sixty members over periods that do not coincide, they produce thousands of lines nobody can justify any more. On the day a member disputes their share, the calculation is not what needs showing: the record of what was retained, and why, is.

What we build

MEKANO is a Lyon-based development studio building management software for buying groups and member networks. For a Lyon buying group of more than sixty member companies, working in refrigeration, air conditioning and professional kitchens, we delivered a member and supplier portal, supplier approval workflows, revenue declarations, the rebate calculation engine and a document management system with full-text search across agreements, covering around fifty approved suppliers. The stack is Go, React and PostgreSQL; source code and documentation are handed over.

We work at a fixed price, in batches. One process — usually declaration collection or rebate calculation — goes live before the rest is committed, so the next stage is funded on an observed result rather than on a promise.