
Costs and pricing
Part of Marketplace seller software costs and pricing: building a budget from list prices
Marketplace software invoice variances: how to investigate
Already using a marketplace seller software budget template? This guide covers invoice checks, VAT evidence and when to reforecast.
A fictional England merchant uses its marketplace seller software budget to review an invoice that appears higher than planned. The approved budget remains the reference point; the task is to trace the difference through dated evidence, distinguish settled cash from forecasts, and decide whether changed facts warrant another budget version.
The invoice creates a case, not a new baseline
The invoice is treated as a variance to investigate, not permission to replace the approved budget. The fictional England merchant fixes the comparison to one seller legal entity, one authorised marketplace account and one approved budget version before looking for a cause.
The record uses the seller's own records, currency and approval ceiling, while earlier versions remain intact. This example stays fictional, and unsupported entries stay blank rather than becoming assumptions. Those limits let the merchant compare the invoice with the approved case, not with later assumptions or remembered details.
- Seller legal entity.
- Marketplace and authorised account.
- Product population.
- Reporting period and timezone.
- Currency.
- Price base date.
- Approval ceiling.
Scope and baseline fields
- Seller legal entity and establishment
- Marketplace and authorised account
- Product population and identifiers
- Source system and current process
- Start and end dates, timezone
- Currency and price base date
- Decision owner and approval ceiling
Any change to the account, product population or reporting period is noted, with a decision on whether a new budget version is needed. Each can affect a like-for-like comparison, so the original baseline is not silently edited to make actual spending appear to match.
Observed work records describe the existing process. Internal hours displaced by software count in economic cost, but remain separate from supplier cash in the whole-life cost ledger. That ledger organises review lines; it does not predict what any line should cost for this merchant.
Rebuild the promise behind the charge
The merchant reconstructs the supplier evidence behind the approved amount. Every price record retains its source and applicable terms together; if dated evidence is missing, the comparison stays on hold rather than treating an empty field as a zero price.
The supplier price record contains these details, with the dated source kept beside the terms so the amount can be checked in context.
- Legal supplier.
- Service.
- Edition.
- Amount and currency.
- VAT status.
- Billing period.
- Term and renewal.
- Dated first-party source.
The charging meter is checked before invoice matching: the billable event and the supplier's treatment of cancellations, returns, partial refunds and disputes. The pricing model keeps that meter visible. If invoice detail conflicts with the price record, the contract terms and vendor due diligence are checked before naming a cause.
Follow the bill through the ledger
At the reporting date, the merchant compares the invoice with the approved amount on the matching ledger row. Applying the same cost categories and evidence checks each time connects this review to the original whole-life cost structure and prevents an unexplained difference becoming a detached total.
The categories stay distinct, and each row carries a unit, quantity, covered period and VAT decision before an actual is accepted.
- Discovery and product-data repair.
- Configuration, interface and migration.
- Supplier, hosting and extension charges.
- Consumer, safety and accessibility review.
- Privacy, PECR and security assurance.
- Operation, reconciliation and support.
- Correction, incident, export and exit.
Whole-life cost ledger rows
- Discovery and product-data repair
- Configuration, interface and migration
- Supplier, hosting and extension charges
- Consumer, safety and accessibility review
- Privacy, PECR and security assurance
- Operation, reconciliation and support
- Correction, incident, export and exit
These categories locate a variance; they do not imply that every cost appears on the supplier invoice. Product-data repair time remains an economic cost rather than supplier cash. Exit evidence belongs on its relevant line, including the notice period, termination trigger and mechanics, required export, deadline before access ends, post-termination retention period and migration work.
An agreed CSV or JSON extract may cover listings, orders, stock and customer records. The merchant retains the export requirements and timing as evidence for the relevant cost line, rather than leaving exit work outside the approved plan or losing it in an unrelated category.
The buyer keeps agreed sums, amounts already invoiced or paid, and expected sums in separate cash states. That separation stops unlike figures being blended and lets each invoice be reconciled with its evidence. A forecast remains a forecast until the supplier commits to it or the scenario is dropped.
| Amount type | Evidence to keep | Review when |
|---|---|---|
| Committed | Dated quotation or order, with unit, period and term | The supplier invoice arrives |
| Incurred | VAT invoice and payment record | The amount is matched to a ledger row |
| Forecast | Stated volume, meter, and buyer low and high scenario | The supplier commits, or the scenario is dropped |
For every ledger row, the merchant records its approved budget version, reporting date, evidence owner and variance reason. A forecast also needs its source, owner, unit, period, low and high scenario, confidence and recheck trigger. Unsupported fields stay blank: an estimate is not an actual, and a blank field does not confirm zero spend.
The same reporting line stays beside each invoice so its amount and variance can be traced to the approved version, supplier offer and supporting evidence. The buyer completes the record at each reporting date rather than relying on an unstructured total.
Field / Buyer entry
- Budget version and reporting date
- [enter version and date]
- Ledger row and exact supplier offer
- [enter row and offer]
- Amount type
- [committed, incurred or forecast]
- Unit, quantity and period
- [enter unit x quantity, period]
- Net amount, currency and VAT status
- [enter reviewed value]
- Variance and reason
- [enter difference and cause]
- Evidence owner and dated source
- [name owner, cite record]
The review then follows the same evidence path for the invoice that appears higher than planned. The merchant checks the ledger row and dated price, compares unit, quantity and period, tests the meter against the event charged, and reviews VAT apart from the net amount before recording the reason and evidence owner.
- Locate the invoice's ledger row and the dated price evidence attached to it.
- Compare the invoice unit, quantity and period with the evidence.
- Check the meter definition against the event charged.
- Review the VAT line separately from the net amount.
- Record the reason, evidence owner and whether another budget version is needed.
Keep the unresolved variance open
The checks do not establish why the invoice appears higher, so the merchant records the explanation as unresolved. An assumption is not promoted to fact; the owner and the remaining question are written down for follow-up.
The buyer applies the same chosen sign convention to over-plan and under-plan entries, writing the cause beside the variance rather than hiding it in a combined total. Where an entry includes net spend and VAT, the reviewed VAT effect is separated so it can be checked on its own.
Unit, period and quantity are confirmed before attributing the difference to changed volume or supplier charges. A favourable variance caused by skipping safety or accessibility work is not a saving; the merchant leaves that apparent saving unaccepted until the assurance requirement has been reviewed.
An unresolved amount does not itself justify changing the approved baseline. A reforecast is triggered only when the basis behind the budget changes, not to tidy the latest figures or rewrite earlier approval. Changes to supplier edition, charging meter, volume, marketplace interface or product scope qualify.
The merchant also reassesses the budget if its VAT view or an assurance requirement changes. When reforecasting is needed, a new dated version is created while the earlier one is preserved; the record states what changed, the supporting evidence, its owner and the affected rows.
When to reforecast
Supplier edition, charging meter, volume, interface or scope changed?
Reforecast the budget version
Keep current forecast
The new version keeps the approved baseline distinct from the latest forecast and cash already incurred. The buyer sets a seller-specific tolerance and escalation owner rather than borrowing a limit from another merchant or supplier case. A price missing currency, VAT status, unit, period, term or dated evidence stays on hold.
Close the review with VAT evidence
The close-out separates supplier VAT from VAT on marketplace transactions. The merchant does not infer recoverability from a software screen displaying a net figure; each treatment sits on its own reviewed line, and uncertain cases go to the buyer's accountant.
Input VAT is normally recoverable only when the buyer is VAT-registered, holds a valid VAT invoice and uses the purchase for taxable business purposes. If those conditions are not met, VAT becomes part of the ledger cost. The merchant checks the invoice rather than assuming every charge receives the same treatment.
UK-established marketplace commission, listing and subscription fees normally carry UK VAT at the standard rate of 20%. The merchant checks that treatment against the invoice instead of automatically applying it to a different kind of charge. Supplier VAT remains separate from VAT on marketplace transactions in the budget.
For services purchased from an overseas supplier, the place-of-supply rules and reverse charge may apply. The merchant refers the treatment to the buyer's accountant rather than copying the handling used for a UK supplier. A change in VAT registration status prompts a review of the budget treatment and consideration of a reforecast.
Businesses have to register for VAT if their VAT taxable turnover is more than £90,000. For the record-keeping position of VAT-registered UK sellers, the merchant follows applicable HMRC guidance and asks the buyer's accountant to confirm the treatment of each charge. VAT records remain part of the review evidence.
Rules the merchant carries forward
The case closes with the approved baseline preserved and invoice evidence, cash states, VAT treatment and open questions brought together. The next review can repeat the same checks without presenting unsupported amounts as settled or altering the original plan to fit actual spend.
- Confirm the baseline version and reporting date.
- Match each invoice to a ledger row and dated price evidence.
- Keep committed, incurred and forecast amounts separate.
- Record supplier VAT and marketplace-transaction VAT on separate reviewed lines.
- Reforecast if the edition, meter, volume, interface, scope, VAT view or assurance requirement changed.
- Hold a price without currency, VAT status, unit, period, term or dated evidence.
For each variance, retain the evidence checked, the recorded reason, its owner and any open question. Use the same categories and sign convention at the next review, keep earlier budget versions intact, and refer VAT decisions to the buyer's accountant whenever the evidence does not settle the treatment.



