Solution

Software for collecting members' revenue declarations

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

60+

member companies file their revenue on a platform we delivered

~50

suppliers whose returns are reconciled against member declarations

One close

a locked, timestamped period whose base goes straight into the calculation

Software for collecting members' revenue declarations does not justify itself on data entry comfort. It justifies itself because collection is the most tedious process a central buying body runs — and above all because what a member declares never quite matches what their supplier invoices. The subject is not the form: it is the gap.

The most tedious process in a buying group

Nothing in a member network consumes as much administrative time as collecting declarations. It is not difficult work, it is chasing work. Every quarter someone at head office opens a tracking sheet, sees that eighteen members out of sixty have replied, sends a first blanket reminder, then a named one, then picks up the phone.

  • Files arrive by email, with columns that change from one member to the next and sometimes from one quarter to the next.
  • Amounts are sometimes net of tax, sometimes gross, sometimes net of on-invoice discount, with nothing in the file to say which.
  • One member declares by supplier, another by brand, a third by product family.
  • Corrections arrive afterwards in a second email, occasionally overwriting an entry already consolidated.
  • At any given moment nobody knows who has filed, who has filed partially, and who has sent nothing at all.

So the real cost is not the typing: it is the manual rework. Normalising files, recoding supplier labels, rebuilding periods, and deciding without any trace which figure to keep when two sources disagree.

Open, chase, close: treating the campaign as an object

  1. Opening the window

    The period opens on a chosen date with an announced deadline. Each member sees what is expected: which suppliers, which period, which basis for the amounts.

  2. Entry or upload

    Online entry for small volumes, an upload against an imposed template for the rest, and last period's lines carried forward so nobody faces a blank page.

  3. Checks at the point of entry

    Supplier not approved for that period, a zero where there was a figure last quarter, a swing beyond a threshold: the anomaly is raised with the member, not discovered three weeks later at head office.

  4. Automatic reminders

    A prompt before the deadline, one on the deadline, then named chasers to the stragglers. Head office follows a progress board rather than an inbox.

  5. Closing the period

    The period is locked. Later corrections remain possible, but as dated and justified adjustments, never as a silent overwrite.

Emailed spreadsheets versus structured declarations

Free-format file collectionStructured declaration
FormatFree, different per member and sometimes per quarterOne template, approved suppliers, explicit unit and basis
Campaign trackingA hand-kept sheet, out of date the moment an email landsContinuous progress view: filed, partial, late, flagged
ChasingManual, time-consuming, often badly receivedAutomatic and dated, with the history of reminders sent
CorrectionsA second file by email, sometimes without mentioning the firstA traced adjustment with author, date, reason and original amount
Feeding the calculationRe-keyed or copy-pasted into the rebate workbookThe base is read directly by the rebate engine
Later verificationImpossible without reopening the original emailsEvery retained line keeps its source, its date and its author
What structuring changes: campaign control and traceability, far more than typing speed.

The real subject is reconciliation, not data entry

Once the declarations are in, the serious work starts. Revenue declared by the member and revenue invoiced by the supplier never match exactly. That is not a defect, it is structural: the two sources measure different things at different moments. A group that automates entry without tackling reconciliation has moved the problem one step along.

Period offset

A late-December order invoiced in January. The member declares at order or delivery, the supplier reports at invoice.

Scope of the base

The supplier reports everything invoiced; the agreement rebates one family only, or excludes carriage, packaging and installation work.

Basis of the amount

Gross, net of on-invoice discount, with or without settlement discount: two equally defensible definitions produce two different figures.

Purchases outside the group

The member buys directly from the same supplier, outside the approval agreement. The supplier reports it all; only part of it is rebateable.

Identifying entities

A multi-site member invoiced under several customer accounts at the supplier, with no obvious common key between the two registers.

Credit notes and disputes

Returns, commercial credits, cancelled invoices: rarely reflected in a declaration already filed, almost always present on the supplier side.

Settle the gaps, then lock

Reconciliation is not about making discrepancies disappear, it is about qualifying them. Most are settled by a rule, once and for all; the rest need a human decision, which has to stay attached to the line it concerns.

  1. Import supplier returns against the agreed template, with the exact period and scope they cover.
  2. Automatic matching of member, supplier and period through a customer-account mapping table maintained inside the tool.
  3. Ranking of discrepancies by likely cause and by amount, so the weight is handled first and the rest falls to rules.
  4. Arbitration: source retained, amount corrected where needed, reason and author kept with the line.
  5. Close the period and pass the base to the rebate calculation, with no re-keying and no intermediate export.

How we deliver this batch

MEKANO is a Lyon-based development studio building the management software of buying groups and member networks. We deliver at a fixed price, in two-week batches, on a Go, React and PostgreSQL stack, and the source code is yours. The declaration module almost always ships with the portal that carries it: declarations cannot be collected without an authenticated space members log into, and a portal without an obligatory process stays empty.

Scoping and the prototype — declaration window, import template, campaign tracking screen on a sample of members — take three weeks and sit between €6,000 and €10,000 excluding VAT. Supplier reconciliation comes in the following batch, once we have seen your real files: that is the only honest way to price it.

Frequently asked questions

Can we keep accepting spreadsheets from members who insist?
Yes, but as an upload against an imposed template, not as a free attachment. The difference matters: a template is validated on import, rejected when badly filled in, and leaves a dated trace. A free attachment forces someone at head office to rework it by hand, which is exactly the cost the project removes. High-volume members keep their usual extract without you inheriting their format.
What about members who never file on time?
Make lateness visible rather than absorbing it. The tool shows progress per company, sends dated reminders and keeps their history — which lets you say, in committee or in general meeting, who meets the deadline and who makes others miss it. Some groups go further and attach a contractual consequence: payment deferred to the next quarter, or the base frozen at the previous declaration.
Can suppliers upload their own invoiced revenue?
That is the mode we recommend as soon as reconciliation is in scope. The supplier uploads their file into their own area, against the agreed template, for the period and scope they cover. They see neither member declarations nor other suppliers' data. Direct upload removes the trip through head office's inbox, which is where files go missing and versions get mixed up.
How often should members declare?
Quarterly is the usual compromise: frequent enough that memories are fresh and that a useful rebate forecast can be produced, spaced enough not to become a burden. Monthly earns its place when supplier returns are monthly and you want to reconcile continuously. Annual is rarely workable: reconstructing a whole year brings back every problem the collection was meant to avoid.
Can past declarations be migrated?
Yes, and we recommend at least one complete financial year. That history does two jobs: it checks the coherence of the first campaign's entries against the equivalent period, and it feeds growth-conditional rebates, which need the previous year to exist at all. Migration is priced during scoping, based on the real state of the files, not billed as an extra afterwards.

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