Integrating CSB-System with a B2B ordering platform: what actually syncs

CSB-System is a German-origin ERP and production management platform built specifically for food, meat, fish, poultry and dairy businesses — one of the few ERP vendors whose core design assumptions match the operational reality of NZ food manufacturing and distribution. It handles catch weight, lot traceability, cutting yield, multi-temperature warehousing and MPI compliance as first-class features, not afterthoughts bolted onto a general-purpose accounting system.

That specialisation is exactly what makes it powerful and exactly what makes connecting it to a B2B trade portal more involved than integrating a general-purpose accounting system like Xero or MYOB. This guide covers what actually needs to sync, where the complexity lives, and the integration approaches that hold up in production.

The data flows a CSB-System integration needs

A working integration between CSB-System and a B2B ordering platform involves six areas of data. Gaps in any of them typically only surface once real order volumes are flowing — not in a demo environment.

1. Customer / account master

Customer records in CSB-System hold account identifiers, trading names, delivery addresses, payment terms, price group assignments and account status. This data determines who can log in to the portal, which delivery options they see, and whether they are permitted to place an order at all. Account status changes — a customer placed on hold, a new delivery address added — need to propagate to the portal before the customer's next ordering session, not at the following day's overnight sync.

2. Product and cut catalogue

CSB-System's product master reflects the reality of food processing: a single raw material (a carcase, a primal) can yield multiple distinct finished products — specific cuts, trim grades, offal — each with its own product code, description, unit of measure and pricing basis. The portal catalogue needs to reflect these distinctions accurately. Product codes added by procurement, seasonal cuts introduced or discontinued, unit-of-measure changes — all need to propagate promptly. The integration also needs to handle CSB's item flags: active/inactive status, whether a product is available to order versus production-only internal use, and any customer-group restrictions on what each account can see and buy.

3. Customer-specific contract pricing

This is the hardest part, and it deserves its own section below.

4. Stock availability

Available quantities in CSB-System are typically held by lot, location and temperature zone. A chilled store, a frozen store and a processing holding area may each carry separate stock records for the same product. The integration needs to determine which quantities are available to promise on the portal — which locations to include, how to handle product that is in a processing queue versus immediately available to dispatch, and what to show for variable-weight items where "quantity in stock" is an approximation based on estimated unit weights. These are business policy decisions that the integration enforces, but that your operations team defines.

5. Orders from portal into CSB-System

When a customer confirms an order on the portal, it needs to flow into CSB-System as a sales or dispatch order — correctly attributed to the customer account, with the right product codes, quantities, requested delivery date and any special instructions. That CSB order then drives pick and pack in your warehouse or processing floor. A failure here — an order confirmed on the portal that never appears in CSB-System — is the worst possible outcome and the first thing your monitoring needs to detect.

6. Invoices, dispatch documentation and AR status

Once CSB-System dispatches an order, confirmed weights, lot references and final prices should flow back to the portal so customers can access their dispatch documentation and invoice history from their portal account. For distributors running high invoice volumes, this also feeds the accounts receivable view — outstanding balances and credit limit utilisation — that the portal checks before permitting the next order to proceed.

Why variable-weight pricing complicates portal checkout

Most B2B portals are designed around fixed-quantity, fixed-price ordering: the customer selects a quantity, sees a line total, confirms the order. That model breaks down for variable-weight products — items where the actual weight of each physical unit varies and is only confirmed at dispatch.

In a CSB-System environment, common examples include fresh meat portions sold by the kilogram (a tray of scotch fillets labelled "approx 1.2 kg"), fresh fish, bulk produce, and cut-to-order items. The customer wants to order "10 trays of ribeye," but each tray has a different actual weight. The final invoice reflects the weighed weight of each tray dispatched, not a nominal fixed quantity.

A portal integration that handles this correctly shows a price per kilogram and an estimated weight and estimated order total at checkout, creates the order in CSB-System at the estimated quantity, and then adjusts the invoice once actual dispatch weights are confirmed. In practice, the customer experiences three touchpoints:

• An estimated order value at checkout
• A confirmed dispatch document showing the actual weight of each unit dispatched
• A final invoice reflecting the actual kilograms delivered

Standard e-commerce checkout flows do not accommodate this. Building it correctly requires the portal to carry explicit catch-weight order logic — the same logic covered in more detail in our guide to catch weight inventory for NZ food distributors.

Contract pricing adds a further layer. CSB-System customers in the meat and food industry often operate on negotiated prices — a specific price per kilogram for a customer's weekly standing order volume, separate from any published price list. The integration needs to resolve each customer's effective price per product at the point the portal displays the product list, not simply copy a single base price to every account.

Lot traceability and MPI compliance

For NZ food businesses, lot and batch traceability is not optional — it is an MPI regulatory requirement and an operational necessity for managing product recalls. CSB-System handles this natively: every unit of stock carries a lot reference that traces back through the supply chain to origin.

A CSB-System portal integration must preserve that chain. When CSB-System allocates stock to a portal order, the lot identifiers assigned to that order must flow back to the portal's order records — not just the product codes. In a recall event, your operations team needs to pull every order that included product from the affected batch and know exactly which customers received it. An integration that records only product codes and quantities without lot references cannot support that workflow.

This requirement also shapes the order confirmation flow. The portal should not issue a final order confirmation to the customer before CSB-System has allocated stock and recorded lot references. Some integrations confirm the portal order immediately and write to CSB asynchronously — a reasonable shortcut for many systems, but one that breaks the traceability chain for food. The correct approach is to confirm the order when the CSB sales order is created and lot allocation is recorded, or to hold the customer's confirmation in a pending state until that happens.

Technical integration approaches

CSB-System deployments vary in age and configuration, and the right integration approach depends on what your specific installation supports.

Web services and REST APIs

Newer CSB-System installations and hosted deployments expose REST or SOAP web services covering customer records, product catalogue, pricing, order creation and fulfilment data. This is the preferred approach for writes — creating sales orders, updating customer status — because it uses CSB's own business logic and validation. It is also the most maintainable across CSB version upgrades. If your CSB-System is on-premises, the same bridging decisions apply as with any on-premises ERP: you need to decide how a cloud-hosted trade portal reaches a service running inside your network.

File-based exchange

Many CSB-System installations — particularly those that have been running for five or more years — rely on scheduled file exports for integration: CSV, XML or proprietary CSB formats written to a shared location at defined intervals. File-based exchange is reliable and requires no inbound network access to your servers, but it introduces latency: a price change or stock update only appears on the portal at the next file cycle. For low-frequency data (product catalogue updates, monthly contract price reviews) this is often acceptable. For high-frequency data (live stock levels, real-time order confirmation) it usually is not.

Hybrid approaches in practice

Most production integrations with CSB-System use a combination. File-based exchange handles bulk catalogue and price refreshes — overnight or twice daily — while direct API or queue-based integration handles time-sensitive flows: order writes, real-time stock availability checks and invoice confirmation. This balances the simplicity and robustness of file exchange with the responsiveness that customer-facing ordering requires. The split between what uses each approach is a decision made during the integration design phase, based on your CSB version, your network architecture and the service-level expectations of your customers.

What a production integration needs beyond the data flows

Once the data flows are working, the gap between an integration that passes testing and one that runs reliably for years comes down to operational instrumentation:

• Order write monitoring. Every order placed on the portal should appear in CSB-System within a defined window — typically minutes. An alert when an order has not been confirmed in CSB within that window is the most important signal to have in place before go-live.
• Pricing freshness alerts. If customer contract prices have not refreshed within a defined period, flag it before the next ordering session — not after a customer has placed an order at an incorrect rate.
• Catch weight variance tracking. Monitor the difference between estimated and invoiced weights over time. Persistent large variances may indicate that the estimated weights used for portal display need recalibrating against current production yields.
• Lot traceability audit capability. The ability to pull every portal order that contained product from a specific batch, on demand, without manual reconciliation — this is what makes an MPI recall manageable rather than a crisis.

CSB-System is a specialist system to integrate with, but the NZ food businesses that run on it — meat processors, cold-chain distributors, food manufacturers — are precisely the operations where a proper B2B trade portal delivers the most return: high order volumes, complex variable-weight pricing, and compliance requirements that generic platforms cannot meet. Getting the integration right is the prerequisite for that return.

For context on how catch weight and variable pricing work in the broader inventory picture, our guide to catch weight inventory for NZ food distributors covers the inventory side in more detail. If you're deciding whether to extend your current CSB-System deployment or consolidate onto a purpose-built platform, the replace vs integrate decision framework covers the signals to look for. And if you want to discuss what a CSB-System integration would involve for your specific operation, reach out to the Zeabyte team — we work across 25+ accounting and ERP systems including CSB-System, Accredo, Attaché, MYOB, SAP and Xero.