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 that automating deferred payment in 1C-Bitrix reduces overdue payments by 2–3 times. The system calculates dates, sends reminders, and blocks payment until the due date.
For a company with 500 orders per month, automation produces annual savings calculated after an audit — by reducing overdue payments and manual labor costs.
Over the years, we have delivered more than 50 B2B projects on Bitrix with deferred payment, and every solution is accompanied by full documentation.
How to store deferred payment terms
Deferred payment terms are stored in 1C by counterparty contracts. 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 (deferred payment), mixed (partial prepayment) |
UF_PREPAY_PERCENT |
int | Prepayment percentage for mixed |
UF_ACTIVE_FROM, UF_ACTIVE_TO |
date | Validity period of the 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 payment or payment by invoice is availabledeferred— an invoice is automatically created with payment date = order date +UF_PAYMENT_DELAY_DAYS; the online payment button is hiddenmixed— an invoice is issued for the prepayment (X% of the amount), and the remainder is due on the deferred date
The payment date is written to the custom order field UF_PAYMENT_DUE_DATE. In the customer account, this date is displayed explicitly in the orders section.
How to set up payment due date notifications?
An agent running daily checks orders with the "Awaiting payment" status 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 follow-up email + a task for the manager in Bitrix24 (if integration is configured)
- On 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, during order placement we filter the list of payment methods (b_sale_pay_system) via the OnSalePaySystemHandlerList handler — removing "Card payment" and "Yandex.Checkout", leaving only "Issue invoice".
How does synchronization with 1C work?
Data from 1C is loaded on a schedule. An agent checks 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 ensures that the terms are always up to date, even if the manager forgot to update the data in Bitrix.
Common mistakes during implementation
- No duplicate check in the HL block (multiple records for one company)
- Forgetting about the mixed type — the remainder is not carried over, and the client pays twice
- Currency validation is not configured: deferred payment may work only for a specific currency
These pitfalls are avoided at the design stage — the code has been verified 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 logic for your 1C — this provides full control and no limitations. In practice, this approach reduces revision 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 review current contract terms, payment types, and integration with 1C.
- Design — HL block schema, event model, agents.
- Implementation — coding in PHP 8.1+, components 2.0, 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 |
Timelines and cost
Basic deferred payment (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 an audit; the full version is also priced after an audit.
The exact price depends on the complexity of integration with your 1C. Get a consultation for your project — we will provide an estimate within one day.
Experience and guarantees
Over many years in the market, we have delivered more than 50 B2B projects on Bitrix with deferred payment. We provide a code guarantee: we fix issues identified within a month after delivery free of charge. All solutions are accompanied by license documentation.
Contact us — we will set up deferred payment for your B2B catalog as a turnkey solution.
