Why set up deferred payment in 1C-Bitrix?
A B2B client places an order, but the "Pay" button must be hidden — the invoice is issued with a deferred date. If this is not implemented, the company loses control over accounts receivable, and managers manually track hundreds of orders.
Our experience shows: automating deferred payment in 1C-Bitrix reduces overdue payments by 2–3 times. At the same time, the system calculates dates itself, sends reminders, and blocks payment until the due date.
For a company with 500 orders per month, automation provides annual savings calculated after audit — due to reduced overdue payments and manual labor costs.
Over the years, we have implemented more than 50 B2B projects on Bitrix with deferred payment, and each solution is accompanied by full documentation.
How to store deferral terms
Deferral terms are stored in 1C in the context of contracts with counterparties. In Bitrix, we duplicate them in the Highload block b2b_payment_terms:
| Field | Type | Description |
|---|---|---|
UF_COMPANY_ID |
int | Company ID |
UF_PAYMENT_DELAY_DAYS |
int | Number of deferral days (0 = no deferral) |
UF_PAYMENT_TYPE |
enum | prepay (prepayment), deferred (deferral), mixed (partial prepayment) |
UF_PREPAY_PERCENT |
int | Prepayment percentage for mixed |
UF_ACTIVE_FROM, UF_ACTIVE_TO |
date | Validity period of terms |
Synchronization from 1C when contract terms change — via an agent or webhook. We use CommerceML for seamless exchange.
Order placement logic
When an order is created, the OnSaleOrderSaved handler reads the company's payment terms:
prepay— standard logic, card or invoice payment is availabledeferred— an invoice is created automatically with payment date = order date +UF_PAYMENT_DELAY_DAYS, online payment button is hiddenmixed— an invoice for prepayment (X% of the amount) is issued, the remainder — on the deferred date
The payment date is written to the order's custom field UF_PAYMENT_DUE_DATE. In the customer's account, in the orders section, this date is displayed explicitly.
How to set up payment due date notifications?
An agent that runs daily checks orders with the status "Awaiting payment" whose UF_PAYMENT_DUE_DATE is approaching:
- 3 days before — email reminder to the client via
CEvent::Send()with theB2B_PAYMENT_REMINDERtemplate - On the payment date — a second email + a task for the manager in Bitrix24 (if integration is configured)
- The day after the deadline — an entry in the overdue log, a flag in
b2b_credit_status
Integration with delivery and payment methods
For clients with deferred payment, when placing an order, in the list of payment methods (b_sale_pay_system) we filter through the OnSalePaySystemHandlerList handler — remove "Card payment" and "Yandex.Kassa", leaving only "Issue invoice".
How does synchronization with 1C work?
Data from 1C is loaded on a schedule. An agent checks for contract updates in the CommerceML export once an hour. If the deferral days or payment type have changed, the record in the HL block is updated.
This guarantees that the terms are always up to date, even if the manager forgot to update the data in Bitrix.
Typical mistakes during implementation
- No duplicate check in the HL block (multiple records for one company)
- They forget about the mixed type — the remainder is not carried over, and the client pays twice
- Currency check is not configured: deferred payment may work only for one currency
We avoid these pitfalls at the design stage — the code has been tested in 50+ projects.
Why is our solution better than standard modules?
Ready-made modules from the marketplace often do not account for B2B specifics: different deferral types, mixed payment, flexible notifications. We write the logic for your 1C — this gives full control and no limitations. In practice, this approach reduces modification time by 4 times.
What is included in the work
- Documentation of the data schema and order logic
- Setup of HL blocks, custom fields, and agents
- Integration with 1C via CommerceML or REST
- Testing of all scenarios (prepay, deferred, mixed)
- Handover of access and training for your developers
- Post-release support for 2 weeks
Work process
- Analytics — we analyze current contract terms, payment types, and integration with 1C.
- Design — schema of HL blocks, event model, agents.
- Implementation — coding on PHP 8.1+, 2.0 components, tagged caching.
- Testing — unit tests, integration scenarios, load testing.
- Deployment — rollout to production, error monitoring via log.
| Stage | Duration | Result |
|---|---|---|
| Analytics | 1–2 days | Data schema, requirements |
| Development | 3–10 days | Ready functionality, tests |
| Testing | 1–2 days | Protocol, fixes |
| Deployment | 1 day | Running in production |
Timeline and cost
Basic deferral (deferred only) — from 3 to 5 days. Full implementation with notifications, synchronization, and mixed payment — from 1 to 2 weeks. The cost of the basic solution is calculated after audit; the full version is also calculated after audit.
The exact price depends on the complexity of integration with your 1C. Get a consultation for your project — we will estimate it within one day.
Experience and guarantees
Over many years in the market, we have implemented more than 50 B2B projects on Bitrix with deferred payment. We provide a code guarantee: we fix errors identified within a month after delivery free of charge. All solutions are accompanied by licensed documentation.
Contact us — we will set up deferred payment for your B2B catalog turnkey.