How many channels can it handle?

Channels are configuration: a collection method, a mapping to the common structure and a rate card. Adding one is an onboarding exercise rather than a development project, which is the point of holding the channel-specific behaviour outside the matching engine.

What if a channel changes its report format?

The mapping for that channel changes and the rest are unaffected. Because each channel is normalised on the way in, a format change is contained at the boundary instead of propagating into the reconciliation logic.

Can it tell an over-charged commission from a timing difference?

Yes, because they are separate checks. An over-deduction is a comparison against the rate card. A timing difference is a sale matched to a settlement that has not yet been credited. Reporting them as one number is what makes channel differences unresolvable.

Do we need to give it access to the marketplace portals?

It reads whatever the channel makes available — scheduled report files, exports or an API — through the access you already have. Nothing requires credentials beyond what your team uses to obtain the same reports today.

Does it replace our ledger?

No. It produces a reconciled position and can write it back to the ledger you already run. The channel-level detail behind each figure stays available for the conversations that follow.

Has this been delivered for a customer?

Not as a standalone engagement. The collection, normalisation, rate derivation and chained matching it uses are the same components running in delivered order-to-cash reconciliation, applied across channels rather than across four sources.

← All solutions

Solutions

One ledger for sales that arrive in a dozen shapes

Order, sales and settlement data collected from every marketplace and channel, normalised into one structure, with commission and fees derived from each channel's own rate card and breaks reported per channel rather than as a single unexplained difference.

Book a demo

Per-channel rate cardsCommission and fees derivedBreaks by channel

Receivables

RetailHospitalityN-way matchingAgentic workflowERP write-backAudit trail

The problem

A business selling through marketplaces, its own app, aggregators and stores receives a different report from each of them, in a different shape, on a different cycle, with deductions named differently and netted at different points. Consolidation happens in a spreadsheet, so it happens monthly at best. When the total received does not agree with the total sold, the difference is real but unattributed — nobody can say which channel it came from, whether it is commission charged above the agreed rate, a settlement that has not arrived yet, or an order that was never passed through at all.

What the platform does

Each channel is collected on its own schedule and normalised into one structure: order, sale, deduction, settlement. Every channel carries its own rate card, so commission, payment fees, logistics charges and promotional deductions are derived from what was agreed rather than accepted as reported. The derived figure is compared against the deduction actually taken. Sales are matched to settlements and settlements to bank credits, and every break stays attached to the channel and the order it came from, so a difference is reported as this channel, this deduction, this many orders.

What you get

The consolidated position is a reconciliation rather than a sum. Commission charged above the agreed rate is visible as an over-deduction against the rate card, with the orders it applies to listed. Sales that were never settled and settlements that carry no matching sale are separate categories rather than one net difference. Because breaks stay attached to their channel, a conversation with a marketplace is about a specific set of orders and a specific clause of its rate card, and the position holds at whatever frequency each channel reports on rather than only at month end.

Process

How it works

Four stages. Every channel keeps its own identity through all of them, because a break that has lost the channel it came from cannot be raised with anyone.

01
Collect
Order, sales and settlement files are pulled from each marketplace, app, aggregator and store system on the cycle that channel actually reports on, with each collection logged so a missing file is visible as a gap rather than as a smaller total.
02
Normalise
Every channel's shape is mapped to one structure — order, sale, deduction, settlement — with identifiers, dates and currencies standardised. Deductions named differently by each channel are mapped to common categories so they can be compared rather than merely listed.
03
Apply the rate card
Commission, payment fees, logistics charges and promotional deductions are derived from each channel's agreed rate card and compared against what the channel actually deducted. Accepting the reported deduction removes the only check that would ever find an over-charge.
04
Reconcile and report by channel
Sales are matched to settlements and settlements to bank credits. Unsettled sales, unmatched settlements and over-deductions are separate categories, each carrying the channel and the orders behind it, so a difference is actionable with the party responsible for it.

What it does

Inside the solution

Every channel on its own cycle

Marketplaces, apps, aggregators and store systems report at different frequencies and in different formats. Each is collected on the cycle it actually uses, and a missing file is reported as a gap rather than absorbed as a lower number.

One structure across channels

Order, sale, deduction and settlement mapped to a common shape, with identifiers, dates and currencies standardised, so a comparison across channels is a comparison of values rather than of reporting conventions.

Per-channel rate cards

Commission tiers, payment fees, logistics charges and promotional deductions are held per channel as the agreement states them, including rates that vary by category or by period, and applied as configuration rather than code.

Deductions derived, not accepted

The expected deduction is calculated from the rate card and compared against what was taken. Where the two differ, the over-deduction is quantified and the orders it applies to are listed, which is what a channel will ask for.

Sale to settlement to bank

Matching runs the full length of the chain rather than stopping at the settlement report, so a settlement that was reported but never credited is a distinct finding from a sale that was never settled.

Breaks stay with their channel

Every unmatched record keeps the channel and the order it came from. A pooled difference cannot be raised with anyone; a break attributed to a channel and a set of orders can be.

Returns and cancellations

Returns, cancellations and their associated reversals are grouped against the original order before matching, so a refunded sale nets correctly instead of appearing as both an unsettled sale and an unexplained deduction.

Write-back and audit trail

Reconciled positions can be written back to the ledger, and each figure keeps the source file, the rate card version and the matching pass behind it, so a channel's position can be re-explained without re-running the reconciliation.

Foundations

The VapusFin models behind it

Accounts Receivable Automation

Accounts Receivable

Apply cash the day it arrives, classify every short payment and deduction, and chase the invoices most likely to be collected first.

Details

Continuous Reconciliation

Reconciliation

Match bank, ledger, intercompany and tax accounts continuously rather than at period end, and investigate breaks with their likely cause already attached.

Details

Questions

Frequently asked

How many channels can it handle?: Channels are configuration: a collection method, a mapping to the common structure and a rate card. Adding one is an onboarding exercise rather than a development project, which is the point of holding the channel-specific behaviour outside the matching engine.
What if a channel changes its report format?: The mapping for that channel changes and the rest are unaffected. Because each channel is normalised on the way in, a format change is contained at the boundary instead of propagating into the reconciliation logic.
Can it tell an over-charged commission from a timing difference?: Yes, because they are separate checks. An over-deduction is a comparison against the rate card. A timing difference is a sale matched to a settlement that has not yet been credited. Reporting them as one number is what makes channel differences unresolvable.
Do we need to give it access to the marketplace portals?: It reads whatever the channel makes available — scheduled report files, exports or an API — through the access you already have. Nothing requires credentials beyond what your team uses to obtain the same reports today.
Does it replace our ledger?: No. It produces a reconciled position and can write it back to the ledger you already run. The channel-level detail behind each figure stays available for the conversations that follow.
Has this been delivered for a customer?: Not as a standalone engagement. The collection, normalisation, rate derivation and chained matching it uses are the same components running in delivered order-to-cash reconciliation, applied across channels rather than across four sources.

See it across your own channels

Send us a period of reports from two or three of your channels, with the rate cards, and we will show you the reconciled position and where the deductions and the agreements disagree.

Book a demo

Last reviewed 4 September 2026

One ledger for sales that arrive in a dozen shapes

The problem

What the platform does

What you get

How it works

Collect

Normalise

Apply the rate card

Reconcile and report by channel