Integrating Pronto Xi with a B2B ordering platform: what actually syncs

Pronto Xi is one of the most widely used ERP platforms across NZ and Australian distribution, wholesale, and manufacturing. It handles inventory, purchasing, sales, financials, and warehouse management in a single system — which is exactly what makes connecting it to a customer-facing B2B ordering portal both high-value and technically involved.

This guide covers what a Pronto Xi B2B portal integration actually involves: which data flows are needed, where the complexity lives, the technical approaches that hold up in production, and what separates an integration that passes testing from one that runs reliably for years.

The data flows a Pronto Xi integration needs

A working integration between Pronto Xi and a B2B ordering platform involves six areas of data. Gaps in any of them tend to surface only once real order volumes are flowing — not during a demo.

1. Customer / account master

Customer records in Pronto Xi carry account identifiers, trading names, billing and delivery addresses, payment terms, price level assignments, credit limits and account status. This data determines who can log in to the portal, which delivery locations they see, and whether they are permitted to place an order. Account changes — a customer placed on hold, a new delivery address added, a credit limit revised — need to propagate to the portal before the customer's next session, not at the following day's overnight sync.

2. Product catalogue

Pronto Xi's inventory item master holds product codes, descriptions, units of measure, product hierarchies, active/inactive status, and per-product settings that affect ordering — minimum order quantities, order multiples, whether an item is available for sale or internal use only, and any customer-group restrictions on visibility. The portal catalogue needs to reflect these accurately. New products added to Pronto, items discontinued, unit-of-measure changes — all need to propagate promptly. An out-of-date product list is one of the fastest ways to erode customer trust in a trade portal.

3. Customer-specific pricing

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

4. Stock on hand and availability

Stock quantities in Pronto Xi are held by location and bin, and a distributor with multiple warehouses or storage areas will have stock records across several locations. The integration needs to determine which quantities are available to promise to portal customers — which locations to aggregate, how to handle committed stock already allocated to existing orders, and how much lead time to represent when stock is in transit between locations. These are business policy decisions that the integration enforces, based on what your operations team defines. The more accurately the portal reflects real available-to-promise quantities, the fewer fulfilment exceptions your team needs to manage.

5. Orders from the portal into Pronto Xi

When a customer confirms an order on the portal, it needs to flow into Pronto Xi as a sales order — correctly attributed to the customer account, with the right product codes, quantities, requested delivery date and any special delivery instructions. That Pronto sales order then drives pick and pack, invoicing, and AR. A failure here — an order confirmed on the portal that never appears in Pronto — is the worst possible outcome, and the first thing your monitoring needs to detect. The order write is the most critical direction of the integration.

6. Invoices and accounts receivable status

Once Pronto Xi dispatches an order and generates an invoice, that invoice should be accessible from the customer's portal account — alongside their order history and outstanding balance. For distributors running high order volumes, this also feeds the AR status check the portal performs before permitting each new order: has this account exceeded its credit limit? Is there an overdue balance that should block further orders? Both checks depend on near-real-time AR data from Pronto Xi, not yesterday's balance.

Why customer-specific pricing is the hard part

Pronto Xi's pricing model is more sophisticated than a single price list — which is a feature for your sales team and a challenge for integration. The system supports price levels (customer or customer-group tiers with their own prices across the product range), customer-specific overrides (a price negotiated for a particular account on a particular product, sitting outside the standard tier), quantity breaks (different unit prices applying above order quantity thresholds), and promotional pricing rules (time-bounded discounts or special prices, sometimes customer-specific).

In practice, a typical wholesale or distribution customer has all of these applying simultaneously: they are on Price Level B, they have a negotiated override on three key products they buy in volume, they qualify for quantity breaks on another ten, and this week there is a promotional price on a seasonal item. The portal must show each customer their effective price — the price they will actually be invoiced — when they browse the catalogue. Showing a standard list price is not just inaccurate; for a trade customer who knows their negotiated rate, it destroys confidence in the portal immediately.

A generic connector tool that copies a single Pronto price list to the portal cannot handle this. The integration needs to resolve each customer's effective price per product at query time, accounting for their price level, any account-specific overrides, applicable quantity breaks at the likely order quantity, and any active promotions. This is the technical requirement that separates a purpose-built Pronto Xi integration from an off-the-shelf connector.

Pricing also needs to stay current. When a sales rep negotiates a new rate and updates it in Pronto, the customer should see that rate on the portal at their next session. A daily overnight sync of a static price export will not meet this bar for active wholesale relationships.

Technical integration approaches

Pronto Xi deployments vary in age and configuration, and the right technical approach depends on your specific installation.

REST API via Pronto Xi Sync

Pronto Software ships Pronto Xi Sync as a data synchronisation layer providing REST API access to core Pronto data — customer records, inventory, orders, invoices and financials. Modern Pronto Xi installations support event-driven updates via this layer, meaning changes in Pronto can trigger near-real-time updates to integrated systems rather than waiting for a scheduled poll. This is the preferred approach for order writes (creating sales orders in Pronto from portal submissions) because it uses Pronto's own business logic and validation, and it is the most maintainable approach across future Pronto Xi version upgrades. The API scope and available endpoints depend on your Pronto Xi version and Sync configuration.

Direct database queries

For pricing and catalogue reads in particular, some production Pronto Xi integrations query the underlying SQL Server database directly rather than going through the API layer. This approach can be faster for bulk price resolution (calculating effective prices for a customer's entire catalogue in one query) and is sometimes necessary when the API does not expose the pricing complexity needed. Direct database access is read-only from the integration side — all writes go through the API or Pronto's own interfaces — and it requires careful version management: schema changes in Pronto Xi upgrades can break queries that worked against the previous version. This approach works well in practice but needs explicit maintenance discipline around Pronto updates.

File-based exchange

Older Pronto Xi installations or deployments with specific network constraints sometimes use scheduled file exports for integration: CSV or XML files written to a shared location at defined intervals. File-based exchange is reliable and straightforward but introduces latency — a price change or new product only appears on the portal at the next file cycle. For lower-frequency data (monthly contract price reviews, weekly product catalogue refreshes) this can be acceptable. For time-sensitive data (order confirmations, credit limit checks, real-time stock levels) it is not the right approach.

On-premises deployments and network bridging

Many NZ distributors run Pronto Xi on-premises rather than in Pronto's hosted environment. A cloud-hosted B2B portal cannot make direct API calls to an on-premises Pronto instance without a connection point. The standard approach is a secure outbound connector — a lightweight sync agent running inside your network on the same segment as Pronto — which polls for data changes and forwards them to the cloud portal, and which receives order payloads from the portal and writes them into Pronto. The agent initiates outbound connections only, keeping your Pronto server behind your firewall with no inbound ports required. This architecture is well-established for on-premises ERP integration and is designed and tested as part of the integration project.

Most production integrations use a combination of these approaches: REST API writes for order creation and customer status updates, direct pricing queries for catalogue pricing resolution, and scheduled file or API syncs for bulk catalogue refreshes. The split is decided during the integration design phase based on your Pronto version, hosting configuration, and the service-level expectations your customers have of the portal.

What a production integration needs beyond the data flows

Getting the six data flows working is the foundation. What determines whether an integration runs reliably for years — rather than requiring constant attention — is operational instrumentation built in from the start:

• Order write monitoring. Every order placed on the portal should appear in Pronto Xi within a defined window — typically minutes for an API-based write. An alert when a portal order has not been confirmed in Pronto within that window is the single most important signal to have in place before go-live.
• Pricing freshness alerts. If a customer's pricing data has not refreshed within a defined period, flag it before their next ordering session — not after they have placed an order at an incorrect rate and called to query the invoice.
• Credit limit accuracy. AR balance and credit limit data should never be more than a defined staleness threshold. A portal that allows orders through against an already-exceeded credit limit — because yesterday's balance showed headroom — creates a finance problem that is harder to recover from than a blocked order.
• Pronto version change management. When Pronto Software releases a major Pronto Xi version, schema changes or API modifications can affect the integration. A production-grade integration has a documented test suite that runs against the integration layer after every Pronto update, catching issues before they affect live customers.
• Reconciliation reporting. A daily report comparing order counts and line item totals between the portal and Pronto Xi surfaces discrepancies before they compound. This is the audit trail that confirms every portal order is matched to a Pronto sales order and eventual invoice.

Pronto Xi is used by NZ and ANZ distributors and wholesalers precisely because it handles the complexity of their operations well. Connecting it to a B2B trade portal extends that investment to the customer-facing layer — letting customers order on their own schedule, see their live pricing and stock, and access their order history and invoices without involving your team. Getting the integration right is the prerequisite for that return.

If you are deciding whether to extend your current Pronto Xi deployment with a portal or whether a broader consolidation makes sense, the replace vs integrate decision framework covers the signals to look for. For context on what a B2B trade portal does differently from a generic e-commerce platform, our B2B trade portal vs e-commerce guide covers the key distinctions for distributors. And if you want to discuss what a Pronto Xi integration would involve for your specific operation, reach out to the Zeabyte team — we work across 25+ accounting and ERP systems including Pronto Xi, Accredo, Attaché, MYOB, SAP and Xero, and build and operate the Provender B2B ordering platform that sits on top of them.