Brightpearl and ZigZag
Integration Agency & Consultants
Returns management typically becomes a bottleneck when the physical arrival of goods is disconnected from the ERP. At scale, manual entry in Brightpearl leads to delayed refunds and inaccurate 'available to sell' stock levels.
Cogent2 connects ZigZag and Brightpearl to automate the creation of Sales Credits and inventory updates. By syncing return data directly into your operations and finance system, we help teams maintain inventory accuracy and speed up refund cycles. This removes the need for manual processing and ensures physical stock movements are reflected in your financial records.
Identifying technical gaps in returns workflows
We connect your Brightpearl and ZigZag ERP and Returns solutions quickly, ensuring your tech ecosystem supports efficient operations. Our consulting services are invaluable, with our system audit uncovering inefficiencies and integration gaps between Brightpearl, ZigZag, ERP, and Returns processes. This enables our consultants and your team to take decisive action, helping your systems run smoothly and efficiently. As a result, you can deliver a great customer experience, confident that your technology is optimised for reliability and growth.
Solution Design
Integrating Brightpearl and ZigZag requires a clear stance on inventory ownership and refund triggers. We typically treat ZigZag as the source of truth for return intent and routing, while Brightpearl remains the master for accounting and inventory levels. A primary design decision involves the timing of Sales Credit creation. While real-time credits improve customer visibility, they can complicate reconciliation if processed before the physical goods reach the final warehouse. We often sequence arrival data to trigger Brightpearl updates once items are received at a hub or warehouse. This prevents inventory errors where returns are valued in the system but missing on the shelf. The design ensures finance closes the books with accurate valuations while CX provides reliable updates based on ZigZag tracking.
Mapping ZigZag data to Brightpearl accounting
The integration manages the returns lifecycle by bridging the customer portal with Brightpearl accounting logic. ZigZag captures return intent and physical routing, then pushes arrival data to Brightpearl to trigger the creation of Sales Credits. We prioritise SKU-to-item mapping and status synchronisation to ensure goods are received into the correct Brightpearl warehouse locations.
Brightpearl remains the system of record for inventory valuation and financial reporting. The logic ensures that as goods move through the ZigZag network, the financial fact of that return is reflected in the ERP. Operational monitoring identifies when physical scans do not trigger the expected record updates, preventing inventory gaps and protecting the accuracy of your available-to-sell stock levels.
Orchestrating workflows on secure middleware platforms
Leveraging IPaaS with ISO 27001 and SOC 2 and above security accreditations enables secure, efficient integration between Brightpearl, ZigZag, ERP, and Returns systems. IPaaS simplifies connecting Brightpearl and ZigZag, automating Returns and ERP data flows while maintaining strict compliance. This approach reduces manual effort, increases reliability, and ensures sensitive data is protected, making integrations faster and more secure for businesses handling ERP and Returns processes.
Surfacing status drift and sync exceptions
Dashboards often fail to highlight the most critical returns issue: status drift. A return may show as received in ZigZag but never update in Brightpearl. Our approach surfaces these discrepancies before they impact the financial close. We provide visibility into the hand-off between physical arrival and inventory updates, alerting teams to missing records or SKU mismatches that block automation. Instead of checking every return manually, your team focuses only on exceptions where the data has failed to sync. This allows for faster resolution of inventory gaps and ensures that financial reporting remains accurate even during periods of high return volume.
Defining finance and operations ownership boundaries
Confidence in the Brightpearl and ZigZag operating model rests on clearly defined ownership between Finance and Ops. We hand over a practical guide that details how return statuses in ZigZag translate into inventory movements and credit notes in Brightpearl. Your team learns to monitor the hand-off points daily, identifying and resolving any status drift. Finance typically owns the reconciliation of credit notes, while Ops monitors the flow of physical goods into designated return warehouses. Documentation is delivered as an operational reference for these teams, focusing on exception handling and daily workflows. This ensures the business maintains control over the returns process once the integration is live.
Monitoring data health and record posting
Post-launch, we provide operational monitoring to ensure the Brightpearl and ZigZag connection remains stable. Our support focuses on identifying sync exceptions—such as mapping errors or failed record creation—before they impact your financial reporting or inventory accuracy.
We monitor the health of the data flow and diagnose why records may fail to post as your product catalogue evolves. Your team gains visibility into system behaviour, ensuring that physical return scans correctly trigger the corresponding financial updates in Brightpearl. We focus on keeping the data clean so your finance and warehouse teams do not have to manage the fallout of sync failures or manual data entry gaps.
Common failures
Return disposition and inventory state mismatch.
Operational impact: A returned item is graded in a ZigZag hub, but the corresponding action fails to post in Brightpearl. This leads to 'ghost' inventory, where stock is physically available but not reflected in Brightpearl's stock levels, or damaged inventory is not correctly written off. The finance team cannot trust inventory valuations, and the fulfilment team risks overselling based on inaccurate availability data.
Prevention / Action: Define ZigZag's final disposition status as the exclusive trigger for inventory adjustments and Sales Credit creation in Brightpearl. Sequence the integration so that no inventory movement or credit is processed until ZigZag provides a definitive state (e.g., 'resalable', 'damaged'). Monitor for returns stuck in transit between the two systems and create an exception report for manual review.
Incorrect Sales Credit values.
Operational impact: The Sales Credit created in Brightpearl has a different value from the refund processed for the customer, often due to promotions, partial returns, or shipping fees. This discrepancy breaks the financial audit trail. The finance team is forced into time-consuming manual reconciliations of ZigZag return logs, payment gateway reports, and Brightpearl's general ledger.
Prevention / Action: Source all financial values for the Brightpearl Sales Credit directly from the ZigZag return record, making it the source of truth for the refund transaction. The integration logic must correctly interpret pro-rated line item costs and associated taxes. Disable manual refund capabilities in other systems to ensure all financial movements for returns are channelled through this single, auditable workflow.
Orphaned returns due to SKU mismatch.
Operational impact: ZigZag attempts to process a return for a SKU that is inactive, has been superseded, or does not exist in the Brightpearl item catalogue. The automated creation of the Sales Credit and the related inventory update fails. This leaves CX and operations teams to manually investigate customer queries, identify the correct SKU, and process the return, creating delays and manual workload.
Prevention / Action: Designate Brightpearl as the master source for all product identifiers. The integration should perform a validation check against the Brightpearl SKU list at the point of return initiation in ZigZag, preventing invalid returns from starting. For any failures that still occur, ensure they are routed to an exception queue with clear notifications for the data management or operations team.
Return stock received into wrong warehouse.
Operational impact: The integration posts returned stock to a default or incorrect Brightpearl warehouse, while the physical item resides in a different ZigZag returns hub or third-party facility. This discrepancy corrupts stock location data, making accurate fulfilment impossible and complicating cycle counts for the warehouse teams. It directly impacts the accuracy of stock available to promise to customers.
Prevention / Action: Establish a rigid mapping between ZigZag's physical return locations ('hubs') and the corresponding Brightpearl warehouse IDs. The integration logic must use this mapping to direct all inbound stock from returns. Any return destined for an un-mapped location must be quarantined in a holding queue for manual allocation, preventing it from corrupting live inventory data.
Frequently asked questions
If a customer returns an item, how do we avoid it being counted as stock in both the ZigZag network and in Brightpearl?
Brightpearl remains the single source of truth for your inventory. The integration is configured so that ZigZag passes return data to Brightpearl, but the stock is only added back to available levels when it is physically received and processed at your designated warehouse. This prevents 'ghost wealth' by ensuring a returned SKU is not counted on the balance sheet until it is officially processed back into your own inventory.
How does the integration handle returns that are damaged and cannot be resold?
ZigZag captures the condition of the returned item, known as the 'disposition status', within their portal. This status, such as 'damaged', is passed to Brightpearl, which then triggers rules to place the SKU into a separate non-saleable warehouse or location. This prevents damaged goods from being automatically added back to your saleable stock levels and ensures accurate inventory valuation.
We process returns manually in Brightpearl now. When should we automate this with ZigZag?
The tipping point is when return volumes create a backlog that delays customer refunds and causes inaccurate 'available-to-sell' stock levels in Brightpearl. If your team spends hours creating Sales Credits and restocking items, and this leads to overselling, automation becomes critical. The integration directly connects the physical returns handling process to the inventory and accounting records in Brightpearl.
Does the integration just update inventory, or does it also handle the financial credit in Brightpearl?
It handles both to ensure your accounts are always balanced. When ZigZag confirms a return is processed, the integration automatically generates a Sales Credit in Brightpearl against the original Sales Order. This means the customer's account is updated and the refund is correctly logged financially without the finance team needing to make manual journal entries.
What's a common point of failure for SKU data between ZigZag and Brightpearl?
A common failure occurs if a returned SKU doesn't perfectly match an existing Item record in Brightpearl, for instance, if it has been discontinued. In this scenario, the automated stock update and Sales Credit creation will fail for that specific return, preventing incorrect data from being created. This flags the return for manual investigation to ensure it is processed correctly against the right SKU or as a write-off.