Why tariff setup on a marketplace breaks as sellers grow
When there are only dozens of sellers, tariffs live in the manager's head: who is on which plan, who has a discount, who got their listing limit raised. Tariff setup at that point looks like a couple of rules in the admin panel.
As soon as there are hundreds of sellers and dozens of categories, manual tariffication stops adding up: rules become overgrown with exceptions, seller limits get duplicated in several places, and no one can say anymore why a particular seller pays exactly that much.
Next, seller billing breaks. Tariff rules written for one category, when carried over to an adjacent one, produce a double charge or, conversely, a missed payment.
Seller limits — by number of items, by order volume, by access to promotion — live separately from the tariff and are updated manually.
On a marketplace with hundreds of sellers, this turns into retroactive reconciliation: accounting finds discrepancies a month later, the seller sees a charge they can't explain, and support can't reproduce the calculation.
The cost of such a bottleneck is not just disputed amounts. It's manual operations on every tariff change, the inability to launch a new category without code changes, and the constant risk that limits and the tariff will diverge.
The faster the marketplace grows, the wider the gap between how tariffs are conceived and how they are actually calculated.
Let's break down how this gets resolved: unified tariff rules, seller limits as part of the tariff, and billing that calculates by rules rather than by the manager's memory.
What managed billing delivers: speed, accuracy, predictability
Managed billing is when the tariff, accrual rules, limits, and charges live in a single loop rather than being spread across a marketplace module, custom scripts, and spreadsheets that someone edits by hand.
For 1C-Bitrix and Bitrix24, this means: the tariff is described declaratively, accruals are calculated by an engine based on order events, and discrepancies are caught before the period is closed, not after a seller complains.
Speed of tariff release
A new tariff or a change in terms is a configuration, not development. An engineer describes the subscription composition, thresholds, and recalculation rules, runs it on a test environment, and publishes it.
Release stops being a sprint task and fits into hours, including validation against historical orders.
Accuracy of accruals
Accrual errors almost always stem from desynchronization: an order event processed twice, a limit charged under an old version of the tariff, a manual edit that bypassed the log.
A single billing loop calculates accruals idempotently and writes every change to an immutable log — the share of disputed accruals drops to isolated cases, and for each one you can see which rule and which event produced it.
Predictable period closing
Period closing stops being a crunch: reconciliation runs against the operations log, discrepancies are visible line by line and resolved before finalization.
Closing time shrinks from days of manual reconciliations to a few hours, and the seller report is assembled from the same data as the accrual — no discrepancies arise between billing and reporting.
What this adds up to
Three effects are connected: speed of tariff release without loss of accuracy, accuracy without manual reconciliations, period closing without a crunch.
A single billing loop removes the very possibility of a discrepancy between what a seller was charged and what they see in the report.
Ways to configure tariffs: comparing approaches
Configuring tariffs for a marketplace almost always comes down to the same choice: keep the logic inside the platform or move it outside. Inside — rules in the admin panel that your team sees and edits.
Outside — a separate billing service where the platform sends events and receives ready-made amounts in return. In between — a hybrid, where the calculation lives in the service, while management and reporting stay in the admin panel.
The choice is determined not by how "trendy" an approach is, but by how often the rules change and how many sellers pass through them.
Below is a comparison by applicability conditions and limitations, so that the decision is made based on your inputs, not on a general recommendation.
| Approach | When it fits | Limitations |
|---|---|---|
| Rules in the admin panel | 1-2 tariff grids, infrequent changes, up to several hundred sellers, need for a quick launch | Complex scenarios (tiers, thresholds, individual conditions) turn into cumbersome rules; as the load grows, recalculation falls on the platform |
| External billing service | Many tariffs and promotions, frequent changes, individual conditions for large sellers, need for a history of charges | A separate contour that must be maintained; if the service is unavailable, charges stop — a queue and reprocessing are needed |
| Hybrid scheme | Tariffs change frequently, but management and reporting must stay with your team | Requires a clear boundary: what is calculated in the service, what in the admin panel; synchronization of tariff reference data is needed |
In practice, most often they arrive at a hybrid: tariff rules and reference data are edited in the admin panel, while calculation and charges go through a service that can recalculate retroactively and store history.
This way the team does not depend on a developer for every tariff edit, and the platform does not choke on recalculations as the number of sellers grows.
A limitation worth remembering on any of the three paths: a tariff is not just a number, but also the rules for its application (what is included, from what moment it applies, how it is recalculated upon cancellation).
If this is not fixed in the data model, any approach will produce discrepancies in charges. Describe how your tariffs are structured and who changes them — we will come back with an estimate and a plan for your case.
How we implement tariffication: stages of work
Implementing tariffication is not "turning on a module" but transferring existing agreements with sellers into working billing rules.
That is why we start with an audit: we reconcile price lists, category terms, free placement thresholds, and personal discounts that have lived in spreadsheets and correspondence for years.
The output is a map of rules where, for each seller, it is clear which rate and commission apply and on what basis.
Next, we design the tariffication model: we break the rules down into levels (base, category, individual terms), determine the priorities for their application and the points where charging depends on the order status. Here we also define what happens when a tariff changes mid-period and how refunds are calculated.
- Audit of current rules: we collect price lists, contracts, and exceptions, and find contradictions between them.
- Designing the tariffication model: rule levels, priorities, behavior when a tariff changes and on refunds.
- Configuration in billing: we set up tariffs, links to categories and sellers, and recalculation schedules.
- Migration of historical data: we load sellers, contracts, and balances, and reconcile the amounts line by line.
- Verification of charges on historical data: we run past periods and compare the result with actual invoices.
- Handling discrepancies: we trace every deviation down to its cause — a rule error or a source data error.
- Handover of regulations: we describe how to change a tariff, add a seller, and resolve disputed charges.
Verification on historical data is the key stage.
We run closed periods through the new model and reconcile the total with what was actually billed: a discrepancy of a few cents across a hundred sellers means an error in rule priority, and it must be found before launch, not after the first invoices.
After that, we hand over the regulations and remain on support — tariff changes and charge resolution follow the described process, not starting from scratch again.
What the client receives: configurations, diagrams, regulations
The project ends not with a demonstration, but with the handover of a package that lets the billing system live on without us.
Everything configured in the system is documented as rules, diagrams, and regulations — so that when an engineer changes or the number of sellers grows, the logic doesn't have to be reconstructed from logs.
- Configured tariff rules. Tariff plans, limits, thresholds for moving between tiers, conditions for recalculation and charges — as a configuration, not as "it just evolved this way." A rule can be changed and tested on a test seller without touching production data.
- A diagram of accrual flows. An agreed-upon map: where a sale event comes from, where the commission is calculated, at what point an invoice is generated, how refunds and reversals are reflected. The diagram answers the question "why does the seller have exactly this amount" in a minute, not in half a day of investigation.
- Access policies. Roles for the seller, manager, accounting, and support: who sees accruals, who can make an adjustment, who can only read. Every action on the balance leaves a trace — who, when, and on what basis changed the amount.
- A reconciliation regulation. The procedure for closing a period: which reports reconcile with each other, which discrepancies are considered normal, what to do when there's a discrepancy. Reconciliation stops being a manual "end of month" operation.
- Support instructions. Typical requests — "the amount doesn't match," "a payment didn't go through," "a recalculation is needed" — with a ready-made procedure and the boundary beyond which an engineer gets involved.
- Billing documentation. A description of the tariff model, a reference of invoice and payment statuses, a changelog of rule changes: what was changed and when, so that a new edit doesn't break an old agreement with the seller.
- A rollback plan. How to revert to the previous version of the rules if the new pricing produced an unexpected result, and at what point a rollback is still safe.
The package stays with you: it's enough to develop the tariff grid on your own or hand it over to another contractor without losing context. Describe your task — we'll come back with an estimate and a plan for exactly which of these artifacts you need.
Case study: how a marketplace moved pricing to a unified loop
A marketplace on 1C-Bitrix with several thousand sellers calculated commissions in two places: the storefront accrued them according to rules hardcoded into the code, while accounting reconciled the same transactions in 1С.
Any change to a tariff — a new product category, a tiered discount based on turnover, special conditions for large sellers — went into development and waited for a release.
Accrual discrepancies surfaced only during reconciliation, and up to a quarter of disputed items were handled manually.
What was changed
Tariffs were moved into a separate loop: the rules for storing, calculating, and recalculating commissions became data rather than code. The storefront and the accounting system read the same configuration, so accrual and ledger entry are generated from a single source.
A new tariff is now described by a set of conditions and published without releasing a new build — with an effective date and versioning, so that past periods are recalculated according to the rules that were in effect at the time of the transaction.
Metrics before and after
| Indicator | Before | After |
|---|---|---|
| Share of discrepancies in accruals | up to 6% of transactions | less than 0.5% |
| Time to release a new tariff | 2-3 weeks via release | 1 day by the finance department |
| Closing of the billing period | 8-10 business days | 2-3 days |
| Manual handling of disputed items | every fourth | isolated cases |
The key turned out to be not the calculation itself, but reconciliation: the loop runs accruals against the accounting system daily and shows discrepancies before the period is closed, not after.
The finance department got a tool where a new tariff is configured and tested on historical data before it goes into production.
How is a seller's rate different from a category commission?
These are two different levels of the same calculation system, and they must not be confused. A category commission is the marketplace's default rule: it is tied to a product group and applies to all sellers who do not have individual terms.
A seller's rate is a personal set of rates that overrides the category logic for a specific account: its own placement rate, its own percentage of the sale, its own terms for logistics and storage.
The overlap of rates arises where a seller trades in several categories with different rates, and some items fall under a promotion or an individual agreement.
Here the priority of rules applies: first the personal exception for the item is checked, then the seller's rate, then the category commission, and only at the end the platform's base rate. The first rule that triggers closes the calculation; the others do not apply. Without a strictly fixed order, the same order would be calculated differently on a repeat run.
The calculation logic is built on versioning: every change to a rate is a new record with an effective start date, not an edit of an existing one.
An order placed at the moment the terms change is calculated according to the version in effect on the date of the event, not on the date of recalculation.
This removes the main pain point — discrepancies in reports, when the seller sees one amount in their personal account and accounting sees another in the closing documents.
In practice, setting up rates comes down to ensuring that the rules are described declaratively and checked for overlaps before publication. We run new terms against historical orders and show whose charges will change and by how much — before the rate goes to production.
Technical concerns regarding marketplace billing
Marketplace billing is the part of the system where an error costs the most: an incorrectly charged commission is visible to both the seller and the buyer, and it has to be corrected retroactively.
That is why, before work starts, we lock down the answers to the questions that most often come up during acceptance.
How does tariff migration happen without stopping sales?
We move tariff rules into a separate configuration layer that is not tied to the storefront code. New tariffs are enabled by a flag for a subset of sellers, charges run in parallel under the old and new logic, and discrepancies are reconciled line by line.
When there are no discrepancies, we switch over the rest. Sales and order placement do not stop during this time.
What about backward compatibility for already placed orders?
An order locks in the tariff at the moment it is placed, not at the moment it is charged. Therefore, changing the tariff grid does not recalculate closed deals: old orders continue under their previous terms, while new ones follow the current ones. This removes the main source of disputed charges during the transition.
Can tariff changes be rolled back?
Yes. Each version of the tariff grid is a separate immutable snapshot with an effective date. A rollback is a switch to the previous snapshot, not a manual edit of charges.
Charges already processed are preserved as is, and adjustments are made through separate reversing entries with a reason note.
How is the correctness of charges verified?
The charge audit is built on reconciliation: the total by orders, the total by tariff rules, and the total in the seller's account must match down to the penny. Discrepancies go into a report linked to the specific order and rule.
The report is exported on a schedule, so a deviation is visible the same day rather than at the end of the month.
Is access to our infrastructure required?
To configure tariffs, access to a test environment and an export of anonymized orders is sufficient. Work on the production environment is coordinated separately and carried out during a low-load window.
If there is no test environment, we deploy one as part of the project so that tariff scenarios can be verified before rollout.
Let's discuss your marketplace billing task
To come back with an estimate and a plan rather than generalities, we need input on your billing model. Describe the task in free form — we'll then clarify what's missing and put together a work plan.
What to send to get started:
- your current tariff logic: what plans exist, what's included in each, how charges are calculated;
- where data on sellers and orders comes from — catalog, personal dashboards, external accounting system;
- how invoices are currently issued and payments recorded, where this breaks down;
- examples of disputed situations: refunds, cancellations, mid-period plan changes;
- roles and access: which employees and sellers see and change what;
- timeline constraints and what must not be touched in the current environment.
What we'll clarify in a call with an engineer: billing frequency and recalculation rules, behavior on plan changes and on overdue balances, whether automatic service blocking is needed, how plans relate to order commissions and seller payouts. We'll separately discuss reporting — which slices you need and which the seller sees.
Then the next step is this: we review your materials, ask targeted questions, and come back with an estimate and a plan — stages, scope of work, and what will be required from your side.
If along the way it turns out that part of the logic is easier to cover by configuring the existing environment rather than custom development, we'll say so directly.
Describe the task — we'll come back with an estimate and a plan.