Setting Up Seller Payouts for a 1C-Bitrix Marketplace

Setting up seller payouts in 1C-Bitrix: where the calculation breaks

Payout setup in 1C-Bitrix breaks not at the "money has left" stage, but earlier — where order status and payout amount live in two independent data snapshots.

The order has moved to "completed", while seller commission calculation still sees it in its previous state.

Then marketplace seller payouts appear for orders that have already been canceled, or conversely, the seller waits a week for accrual although the buyer received the goods long ago.

The second typical failure point is the register maintained manually in spreadsheets. Category commission, seller-funded discount, paid delivery, promo deductions, and logistics are calculated by a formula in the manager's head, not in code.

With a few sellers this works; with dozens, it produces a systematic error in marketplace calculations that is found only after a complaint.

Returns and deductions arrive later than the period is closed. A partial return, product dispute, cancellation after shipment — all of this changes the amount of an already generated payout, and without reversal mechanics, a negative or doubled balance remains in the register.

Separately, there is the interface with the payment service. The payout was initiated, no confirmation was received, the operation hung between systems; resending the register leads to a double transfer.

We look at how this is closed: a single register as the source of truth, calculation based on order events, idempotent payouts, and reconciliation with payment service reports.

What a managed seller settlement loop provides

A managed loop is built on order events rather than spreadsheet exports: payment, shipment, return, and cancellation form an entry in the settlement register linked to the seller, line item, and period.

On the 1C-Bitrix side, this means order checkout handlers plus a dedicated calculation rules layer — commission, logistics, and deductions are calculated once and repeatably. Re-running a payout for the same order does not create a second accrual.

Reconciliation of calculations with sellers stops being a one-time task at the end of the month. The statement is generated automatically for the closed period, and the seller sees line by line what made up the amount: order, commission, deduction, return.

A discrepancy does not dissolve in correspondence but is recorded as a line item with a reason and resolved before payout.

Accounting for returns and deductions follows the same logic. A return reverses the accrual for a specific line item rather than using an average coefficient for the period; a penalty or deduction is linked to its basis and date.

A disputed accrual remains visible in its period — it cannot be lost simply by not closing the payout.

The measurable consequence of automating settlements is a reduction in manual operations: standard payouts go out on schedule, while manual review remains for anomalies, whose share falls as rules are configured.

The period closes with a reconciled balance for each seller, and accounting and the seller work with one version of the numbers rather than two spreadsheets.

Ways to organize payouts: comparison of approaches

The method of paying sellers is chosen by three parameters: how many recipients are in one cycle, how often money goes out, and who confirms the amounts.

Reporting and the seller portal are built on top of the chosen scheme, so it is better to lock down the calculation rules before development — reworking them on live turnover is noticeably more expensive.

Below are three options that cover most marketplaces, with applicability conditions and limitations of each.

The choice of calculation scheme rests on the threshold of manual operations: while there are few sellers, the register is simpler to maintain and more transparent for reconciliation.

As the number of recipients grows, automatic operations via the payment service relieve the accounting load, and the hybrid works as a transitional stage — automation is enabled, but control over disputed amounts remains.

Work stages: from calculation audit to handover to support

The work proceeds sequentially: until the current accrual logic is understood, any change to payout rules breaks amounts already agreed with sellers.

That is why we start with a calculation audit and finish with regulations under which the calculations continue to live without us. Below are the payout setup stages in the order in which they are performed on a project.

1. Marketplace calculation audit. We export the history of orders, returns, and settlements, reconcile accruals against source documents, and record discrepancies: duplicated returns, lost line items, commission from the wrong category.
2. Accrual scheme design. We determine what becomes the basis: payment moment, order closure, or deduction period; how discounts, delivery, acquiring, and offset against claims are accounted for.
3. Configuration of rules and permissions. Distribution rules by seller and category, manager roles, limits on manual adjustments, and logging of every amount change.
4. Test payout loop. We deploy a copy of the catalog and orders and run scenarios: full and partial return, cancellation after shipment, payout with a negative balance.
5. Acceptance on real data. We calculate one reporting period in parallel — using the old and new methods — reconcile totals for each seller, and resolve discrepancies to zero.
6. Handover of calculations to support. Data schema, period closing regulations, instructions for standard operations, control points, and rollback procedure to the previous logic.

Documentation, regulations, and operation logs for calculations

Settlements with sellers break not in code but at the moment of review: it is unclear who changed the status, on what basis an accrual was made, and why two sellers have different terms for identical orders.

That is why, together with the calculation module, we hand over a documentation package that support and accounting use to close standard situations without contacting the developer.

• Money and status flow diagram — the path from order payment to closed payout, including returns, partial cancellations, and deductions; it shows at which step an operation may hang.
• Payout access rights matrix — who generates the register, who confirms it, who edits seller details, who only reads the log. The initiator and approver are separated: one person cannot process a payment alone.
• Seller payout regulations — frequency of register generation, commission and rounding rules, procedure for handling a negative balance and seller debt.
• Operations log — for each entry: initiator, time, amount broken down by order, basis, result. Entries are immutable; a correction is made as a reversing line.
• Procedure for reconciliation with the statement — how accruals and actual debits are matched and from what threshold a discrepancy goes to manual review.
• Disputed operation review regulations — response times, responsible persons, seller notification templates, and escalation procedure.
• Instructions for accounting and support — standard scenarios: period closing, register export, suspension of seller payouts upon request.

Case: marketplace reduced discrepancies in seller settlements

A marketplace on 1C-Bitrix with several hundred sellers: payouts went through a register assembled manually from the commission, returns, and logistics report.

Discrepancies surfaced only after transfer — the seller received an amount that did not match their own reconciliation and wrote to support. The settlement period closed in 8–12 business days, and a significant portion of operations required manual correction.

What was changed

The settlement loop was tied to document closing: until the commission report, returns, and logistics are brought together in a single register, the payout is not generated.

Each accrual and deduction received a link to a source document, so a discrepancy is visible before the money transfer, not after. Reconciliation statements and accrual details are automatically exported to the seller portal — both sides see the same picture.

Metrics before and after

Support stopped sorting out arithmetic and took on substantive questions. The same discrepancy reconciliation loop can be transferred to any compensation scheme — we will look at how it can be closed for your catalog and payout rules.

How does automatic payout differ from a manual register?

A manual register is a file with accruals that a manager assembles from reports and uploads to the bank. While there are only a few sellers, the scheme works: the period closes quickly, and disputed amounts are corrected before export.

But as it grows, each new point of sale and each return adds a line that someone must reconcile manually.

An automatic payout calculates commission, deductions, and returns itself, generates a payment order, and sends it on schedule. Period closing shrinks from days to hours, and a discrepancy is visible in the operations log even before the money has gone to the seller. A double payout or unaccounted return becomes an exception rather than a regular occurrence.

The risks of a manual register are most visible in seller support. A dispute about underpayment is handled in correspondence and checked against exports, and each inquiry takes manager and accounting time.

Automation gives the seller a history of accruals and deductions, so the question is closed with an answer from the portal.

The cost of owning the process also differs. Manual mode is cheaper at the start but requires constant human resources and concentrates risk in one employee who maintains the spreadsheet.

Automation is a one-time setup of distribution rules and payout regulations; after that, volume grows, not the number of operations.

Manual seller payouts remain justified if there are only a few sellers and a person confirms each amount; with a regular flow, the choice of calculation scheme shifts toward automation.

Technical concerns: integrations, returns, and repeated operations

A seller payout is a chain: calculation for completed orders, deduction verification, register generation, and transfer to the payment service.

We design the interface so that each operation has an immutable identifier and an unambiguous status — then integration with the payment service does not depend on the response speed of the external system.

For a marketplace on 1C-Bitrix, it is critical that the settlement loop be able to replay events: a repeated payout during a failure, a canceled payment, a return after a payout has already been made. Below are the questions most often asked before work starts.

How do returns and deductions get into the seller's calculation?

A return reduces the amount of the next settlement period rather than "burning" what has already been paid out. A deduction — commission, delivery, penalty — goes as a separate register line with a reason, and the seller sees a breakdown for each order.

What changes when a seller's status changes in calculations?

The status controls only participation in registers: verification, active, suspended. The accumulated balance does not burn but is held pending clarification, and the operation history is preserved and can be restored at any time.

How is sellers' tax specificity accounted for?

The seller's status — self-employed, individual entrepreneur, legal entity — determines the set of closing documents and whether tax is withheld at payout. The scenario is set in the seller's card, and the settlement loop applies it automatically.

Let's discuss your seller settlement scheme

To come back with an estimate for the calculation work and an implementation plan, we need your actual arithmetic, not a general description of the process.

Let's discuss the calculation scheme in a review session: what we will clarify so that the estimate is based on the actual volume of operations and accounting constraints, not on average figures.

Usually, a conversation with accounting and a technical specialist plus access to a test copy is enough. We record:

• Accrual rules: category commission, delivery, penalties, returns, and cancellations — where these rules live today and who changes them.
• Roles of payment scenarios: who pays the seller — the platform or a payment partner, whether separate accounting and a reserve for returns are needed.
• Volume of operations: how many sellers, payouts per period and peak days, what share of calculations is still manual.
• Accounting system constraints: 1C configuration, chart of accounts, exchange with the website, period closing, and requirements for closing documents.
• Responsibility loop: who generates and signs the register, how discrepancies and disputed accruals are resolved.
• Seller reporting: what they see in the portal and what documents they receive — this determines the flow of support inquiries.

Next, marketplace payout setup is broken down into stages with a clear result at each. Describe the task — we will come back with an estimate and an implementation plan for the calculations.