B2B portal development: where order accounting breaks
B2B portal development almost always hits a wall not with the interface, but with order accounting.
While a manager manually transfers a request from email into the accounting system, the client sees one price, but the invoice comes with another — the discrepancy surfaces at the payment stage. Every such error in requests costs a re-approval, and sometimes a lost order.
Price synchronization is the second source of failures.
The price list is updated in the accounting system, but on the portal it remains yesterday's: the contract discount wasn't pulled in, individual terms for the dealer weren't accounted for, warehouse stock diverged from actual.
The client places an order at an outdated price, and then manual correction begins — the very thing the portal was built to eliminate.
Manual order entry is dangerous not because of speed, but because it leaves no trace. It's unclear who changed the quantity, why the price changed, at which step the request lost a line item.
When there are dozens of such orders a day, errors stop being an exception and become the background: returns, shipping disputes, reconciliations that don't match on the first try.
Let's break down how this is closed at the architecture level: a single source of prices and stock, automatic transfer of orders into the accounting system, a change log for each line item.
What the portal delivers: measurable effects for the sales department
Developing a B2B portal delivers an effect that is visible in the sales department's numbers, not in a presentation.
Order processing time drops from hours to minutes: the client builds their own cart using their own item list, sees stock levels and prices under their own contract, and the request goes into the accounting system without retyping.
The manager stops being a data-entry operator — they focus on the deal, not on transferring rows from an email into a spreadsheet.
The share of manual operations shrinks because the portal handles repetitive scenarios: recalculating prices according to agreed terms, checking limits and outstanding debt, populating company details and delivery addresses, generating documents from a template.
Each of these actions used to take a manager minutes and was a source of errors — now it is performed by a rule, identically for all clients.
A separate source of effect is eliminated rejections.
The portal blocks an order at the checkout stage if an item is out of stock, the lead time exceeds what was promised to the client, the amount exceeds the credit limit, or the company details do not match the counterparty's record.
These are the rejections that used to surface at the assembly and shipment stage, when the client was already waiting and the manager was spending time on coordination.
The load on managers stops growing along with the number of clients: the order flow goes through the portal, and manual intervention remains only for non-standard terms. Let's break down how this is handled at the level of integration with the accounting system and access roles.
Implementation options: boxed solution, website builder, custom development
The choice of approach determines not only the launch timeline, but also what you will be able to change in the portal a year or two down the line.
A ready-made platform and a website builder offer a fast start, but their logic is fixed: customer-specific prices, limits, personalized contract terms, and integration with the accounting system have to be fitted into someone else's rules.
Custom development takes longer to get off the ground, but the data model, roles, and integrations are designed around your sales process, not the other way around.
| Option | When it fits | Limitations |
|---|---|---|
| Ready-made platform | A standard catalog, standard prices, integration with the accounting system out of the box | You can only change pricing logic and roles within the vendor's settings; a non-standard ordering scenario runs into the platform's limitations |
| Website builder | A quick storefront launch, a small product range, minimal integrations | Weak portal scalability: complex access rights, order history, and integration with the accounting system require external add-ons |
| Custom development | Individual prices and limits, multiple legal entities, deep integration with the accounting system | Longer time to first version; you need a contractor who will maintain the portal after launch as well |
What to look at when choosing
Don't count the license cost — count the cost of customizing for your scenario: with a platform it grows with every non-standard change, while with custom development it is locked in at the design stage.
Check how the option will hold up to growth: adding branches, currencies, contract prices, and roles.
Where things most often hit a wall
Integration with the accounting system and access rights are the two areas where a ready-made platform and a website builder require workarounds. If these nodes are critical for you, custom development pays for itself with the very first customization.
Stages of work: from accounting system audit to launch
The order of the stages is not accidental: each subsequent step relies on the artifact of the previous one.
If you skip the accounting system audit and immediately start "drawing the portal," integration with 1C will surface at acceptance — and the rework will affect both the data schema and the order logic.
- Accounting system audit. We analyze the 1C configuration: which catalogs and registers are actually used, where the item nomenclature is maintained, how prices and stock are structured, and what customizations already exist. The output is a data map and a list of bottlenecks that cannot be carried into the portal as is.
- Integration schema design. We determine what the portal reads from the accounting system and what it writes back, and in which direction orders, statuses, and prices flow. We fix the exchange protocol, the composition of entities, and the rules for matching item nomenclature — this is the core of all further work.
- Exchange setup. We stand up the service layer between the portal and 1C, configure the synchronization schedule and conflict handling for when an order and stock change simultaneously. Separately, we cover behavior when the accounting system is unavailable — the portal must not lose orders.
- Portal assembly. Personal account, catalog with personalized prices, cart, order history, documents. We separate roles and permissions across managers, clients, and administrators so that each sees only their own data.
- Acceptance checks. We run scenarios on real data: order placement, price recalculation, statuses, document export. We reconcile amounts and stock between the portal and the accounting system — a discrepancy here means an error in the exchange schema.
- Portal launch. We move to the production environment, connect exchange monitoring and synchronization error notifications, and train managers. For the first weeks, we maintain enhanced monitoring of the exchange queue.
After launch, a support regulation remains: how new entities are added, how the accounting system is updated without stopping the exchange. Describe your 1C configuration and processes — we will come back with an estimate and a stage-by-stage plan.
What the customer receives after implementation
Implementation ends not with a launch, but with the handover of a set of deliverables that allows the portal to be operated, developed, and passed on to another team. Below is what exactly remains with the customer.
- Integration diagram — a map of the exchange between the portal, the accounting system, and external services: which entities are synchronized (product catalog, prices, stock, orders, statuses), in which direction, at what frequency, and what happens when discrepancies occur.
- Exchange regulations — rules of behavior during failures: the synchronization window, the procedure for re-uploading, handling price and stock conflicts, the operations log, and the points where the administrator can see the cause of a discrepancy.
- Access matrix — roles for customers, managers, and administrators with differentiation by sections, document types, and operations; permissions for changing prices, confirming orders, and exporting data are documented separately.
- Environment configurations — settings for the portal, integration modules, and queues, the backup scheme, and the procedure for deploying to a new environment without manual assembly "from memory."
- Administrator guide — step-by-step scenarios: adding a customer and a manager, editing the catalog, troubleshooting a stalled exchange, rolling back a failed synchronization, reading logs.
- Portal documentation — a description of the section structure, data model, extension points, and external dependencies, so that further development does not begin with reverse engineering.
- Handover package — access credentials, the deployment diagram, contacts of responsible parties, and a list of known limitations with a plan for closing them.
The package is assembled throughout the work, not at the end: the integration diagram and access matrix are agreed upon before development, the exchange regulations — at the stage of connecting the accounting system, the guides — during acceptance scenarios.
By the time of handover, each part has already been tested on real operations, rather than written formally.
Describe your task — we will come back with an estimate and a plan, including the composition of the documentation to be handed over for your environment.
Case study: how a portal eliminated double order entry
The client came to us with a classic pain point: managers took orders via email and Excel, then manually transferred the same line items into the accounting system. A single order went through two entries, and every reconciliation turned into a separate operation.
We started with a process audit — measured how much time it took to process one order and where discrepancies arose.
What it was like before the portal
Orders arrived in free form: an email, a phone call, a spreadsheet from a regular client. A manager gathered the line items, checked stock availability by phone with the warehouse, and only then created the document.
One order took an average of 40 minutes, and picking errors surfaced only at shipment — the client received something other than what they had ordered.
What we changed
We developed a B2B portal with a personal account: the client sees current stock, prices under their own contract, and order history. An order is placed in the interface and goes directly into the accounting system, without manual transfer.
We set up a two-way integration with 1C — statuses, invoices, and shipments return to the account automatically.
What it became after launch
Order processing time dropped from 40 to 6 minutes: the manager only confirms rather than re-entering line items. The share of orders with picking errors fell from 12% to 1.5% — discrepancies are caught at the ordering stage, not at the warehouse.
The load on the sales department decreased so much that two managers switched to working with new clients instead of routine data entry.
The client confirmed the results using their own internal statistics for the first months of the portal's operation.
They separately noted that we handle support according to a regulation: integration incidents are resolved within one business day, not "when someone gets around to it."
How is a portal different from a customer account on an off-the-shelf platform?
A customer account on an off-the-shelf platform is a layer on top of someone else's data model. The platform defines the structure of entities: user, order, product, invoice.
You can rename sections, add fields, configure permissions — but the relationships between entities remain vendor-defined.
As soon as the business logic diverges from this model (for example, the price depends on a discount matrix agreed with the client, while the platform only supports a fixed price list and a promo code), workarounds begin: external tables, manual operations, one-way synchronization.
A custom portal is designed around the customer's processes, not around a template. The data model, roles, and approval rules are described the way they actually work: who approves an order, at what stage finance gets involved, how the price is recalculated upon partial shipment.
Customizing the logic here is not "patching up" the platform — it is its initial state. That is why integration with the accounting system runs on events in both directions, rather than through batch exports on a schedule.
The limitations of off-the-shelf solutions do not show up immediately, but as the business grows. While orders number in the dozens, the account handles it.
When branches, individual terms, and multiple legal entities under a single client appear, the platform runs up against its own abstractions: some scenarios have to be moved outside of it.
On a custom portal, such branches are built into the architecture in advance — expansion does not break processes that are already running.
The practical selection criterion is simple. If your processes fit a standard scenario — "the client sees a catalog, adds to cart, receives an invoice" — an off-the-shelf platform will solve the task faster.
If your pricing, approval, and shipping logic is unique and constitutes a competitive advantage — an account on a platform will become a constant source of workarounds, while a custom portal will pay for itself on the very first change of rules.
Common technical concerns before starting
Before starting the development of a B2B portal, customers most often raise three topics: whether the portal will withstand peak load, how counterparty data is protected, and how reliably it is connected to the accounting system. Below is an analysis of typical concerns that we address at the design stage, not after launch.
Will the portal hold up if the number of orders grows several times over tomorrow?
We build in a load margin from day one: horizontal scaling of applications, caching of the catalog and stock levels, moving heavy queries to a separate storage.
Peak periods — sales, month-end closing, mass submission of orders — are handled without degradation, because we find bottlenecks during load testing, not in live operation.
Growth in the number of users and orders does not require rewriting the portal — resources are added to the already designed architecture.
How is counterparty data protected and how are roles separated?
Access is built on a role-based model: a manager sees only their own clients, a counterparty sees only their own orders, invoices, and documents, an administrator manages reference data. Data is encrypted in transit and at rest, and user actions are recorded in an audit log.
This satisfies both security service requirements and audit practices: you can see who changed what and when.
How reliable is the integration with 1C and what happens in case of a failure?
Exchange with the accounting system goes through an integration layer with queues and retries: if 1C is unavailable, orders and stock levels are not lost but are loaded once the connection is restored.
We synchronize the item catalog, prices, stock levels, settlements, and order statuses. Backups are scheduled with recovery verification — we know the time to return to operation rather than hoping for it.
Can the portal be launched in stages without stopping sales?
Yes. We move the critical contour — catalog, orders, integration — to the first stage, and connect the remaining modules in iterations. The old order-taking scheme keeps working until the new one proves stable on real data. This way the transition happens without any interruption in customer service.
Describe your task — we will come back with an estimate and a work plan for your contour.
Let's discuss your task and come back with an estimate
We show the workflow for a B2B portal using a real case: a distributor with 4,000 items in its catalog managed orders in email and Excel, and managers manually reconciled stock balances with the accounting system.
The portal was built on 1C-Bitrix with scheduled exchange of product items and prices, a personal account with order history, and a role-based model for wholesale clients.
What changed after launch
The share of orders placed through the portal grew from zero to 70% in the first quarter — managers were no longer the only channel for taking orders.
The discrepancy in stock balances between the portal and the accounting system shrank from hours to minutes thanks to regular exchange, and manual entry of items into orders was eliminated entirely.
What the work plan includes
- audit of the customer's current sales processes and accounting system;
- designing the data model: product items, prices, contracts, roles;
- prototype of the personal account and order placement scenarios;
- integration with 1С: exchange of stock balances, prices, order statuses;
- development and testing on the customer's real data;
- migration to the production environment and training managers;
- post-launch support and improvements based on feedback.
To come back with an estimate of timelines and scope of work, we need access to your accounting system or a product item export, a list of user roles, and an understanding of which order scenarios are critical first. Describe the task — we'll come back with a plan and timelines.
