Stokly ERP and ZigZag
Integration Agency & Consultants
Cogent2 delivers integrations with AI-assisted tooling and operators who understand a P&L. For brands using ZigZag and Stokly ERP, slow returns processing creates inventory and finance blind spots. We connect the systems properly so inventory is consistently accurate and financial reconciliation isn't a painful manual effort at month-end.
Audit of inventory and financial data flow
We connect your Stokly ERP and ZigZag quickly, ensuring your ERP and Returns processes work together efficiently. Our consulting services are invaluable, with our system audit services providing a thorough review of your tech stack. This enables our consultants and your team to identify and address issues, helping your Stokly ERP and ZigZag Returns integration run smoothly. By resolving inefficiencies, we support your business in delivering a great customer experience and maintaining a robust, future-ready technology ecosystem.
Solution Design
For the Stokly ERP and ZigZag integration, we establish Stokly as the authority for stock levels and financial finality. ZigZag acts as the operational trigger for return status updates. A key design decision involves the sequencing of inventory: we typically postpone stock re-entry until a physical scan is confirmed in ZigZag to prevent phantom inventory appearing in Stokly too early. In many setups, we trade off immediate refund processing for scheduled financial reconciliation. This approach helps reduce integration complexity and ensures that finance teams close their books against matched transactions rather than fragmented data. This design ensures that the warehouse team works off accurate physical counts while finance maintains a clean ledger for reporting.
Mapping return triggers to inventory records
The integration manages the flow of return data between systems to maintain inventory accuracy. ZigZag initiates the return status, while Stokly ERP acts as the system of record for inventory levels and financial adjustments. When a return is processed, the outcome updates Stokly to reflect stock availability. We monitor the sync to detect SKU or order ID mismatches early, preventing orphaned records and ensuring that returns are accurately reflected for reconciliation.
Secure orchestration on enterprise grade middleware
Leveraging IPaaS with ISO 27001 and SOC 2 and above security accreditations, Stokly ERP and ZigZag are integrated efficiently and securely, supporting ERP and Returns processes. Using an IPaaS platform simplifies connecting Stokly ERP and ZigZag, reduces manual effort, and ensures data protection. The benefits include robust security, real-time data flow, and easier Returns management, all while meeting the minimum requirements of ISO 27001 and SOC 2 compliance and above.
Surface exceptions between the warehouse and finance
Standard dashboards often report that a return was successful in ZigZag but may not show if that data reached Stokly ERP correctly. This can create hidden stock discrepancies that only surface during a physical count. Our approach provides visibility into the data flow between systems. If a return event fails to post to Stokly, it is surfaced as an exception for the team to address. This helps prevent the compound errors that occur when finance and warehouse teams refer to different sets of data.
Operational handover for finance and warehouse teams
Cogent2’s training equips your team to confidently manage your tech stack, supporting your brand’s growth ambitions with Stokly ERP and ZigZag. Gain practical skills to optimise ERP processes, handle Returns efficiently, and ensure your systems work effectively. With Stokly ERP and ZigZag, your team can address Returns challenges and integration needs, driving operational success and supporting your business goals.
Post-live monitoring and data reconciliation support
We provide ongoing support for the integration, monitoring the data flow between ZigZag and Stokly ERP to catch exceptions before they impact your reporting. If a sync fails or return data drifts, our team manages the resolution process. This reduces the technical burden on your internal teams, ensuring that stock adjustments and financial credits in Stokly ERP remain accurate and reconciled.
Common failures
Returned SKU not found or is inactive
Operational impact: A return processed in ZigZag for a discontinued or incorrectly coded SKU fails to find a match in Stokly ERP. This prevents the stock adjustment, leaving physical stock in the warehouse but not in the ERP. The finance team cannot create the correct credit journal, leading to reconciliation failures and an inaccurate view of returned stock value.
Prevention / Action: Stokly must be designated the exclusive source of truth for SKU master data. Integration logic must include specific error handling to flag any return with an unrecognised SKU for manual review, rather than failing silently. Any non-standard codes from ZigZag, such as for return fees, must be mapped to special service items or GL accounts in Stokly during implementation.
Failed or duplicate inventory adjustments
Operational impact: An API call from ZigZag to update Stokly's inventory levels fails due to a transient network issue or rate limiting, but there is no retry. Consequently, returned items are physically present but not reflected in the stock ledger, leading to inaccurate availability and missed sales. Conversely, a naive retry logic can create duplicate adjustments, artificially inflating stock levels and leading to overselling.
Prevention / Action: Inventory adjustment messages from ZigZag should be processed through a message queue to ensure they are not lost during transit. The integration must employ an idempotent design, where receiving the same message multiple times has no duplicate effect. This is typically achieved by using ZigZag's unique return identifier to check if an inventory adjustment journal has already been posted in Stokly for that return before creating a new one.
Financial reconciliation gaps
Operational impact: The refund value confirmed by ZigZag fails to match the credit note value posted to Stokly, often because of deductions or timing differences. This forces the finance team to perform time-consuming manual checks between payout reports, ZigZag records, and Stokly's general ledger. At scale, this prevents an accurate and timely month-end close and masks the true profitability of sales orders.
Prevention / Action: The integration process must define a single, authoritative trigger for posting financial records. The creation of a credit note in Stokly should only occur after a successful return has been fully graded and finalised in ZigZag. The integration must pass the final refund amount as the definitive value, ensuring that any deductions are automatically accounted for in the corresponding journal entry in Stokly.
Frequently asked questions
How does the integration handle returns sent to different warehouses?
To ensure returned stock is correctly processed, each ZigZag 'Warehouse Code' must be mapped to a corresponding 'Location Code' within Stokly ERP. If a return arrives at a warehouse without a matching code, the integration cannot create the necessary stock adjustment, causing inventory levels in Stokly ERP to become inaccurate. This prevents an accurate, real-time view of stock-on-hand across your network.
What happens if a customer returns a product that is now discontinued?
If ZigZag processes a return for an SKU that has been marked as inactive or archived in Stokly ERP, the integration will fail to update the inventory record. This means the physical item is in your warehouse but does not exist in Stokly's bookable stock, creating a tangible discrepancy that requires manual reconciliation. Maintaining consistent SKU lifecycle management between both systems is critical to prevent this variance.
Which system acts as the source of truth for returned inventory?
Stokly ERP remains the ultimate source of truth for both financial records and final inventory levels. ZigZag manages the returns initiation and grading workflow, but its role is to provide the correct triggers for Stokly ERP to process a stock receipt and any associated credit. This ensures your core ERP contains the authoritative record of stock-on-hand, which is crucial for accurate financial reporting and demand planning.
How are non-product charges from ZigZag, like return fees, handled in Stokly ERP?
Charges like return handling fees must be set up as non-inventory SKUs inside Stokly ERP for the integration to process them correctly. If ZigZag sends a financial adjustment referencing a charge SKU that Stokly does not recognise, it will cause a sync error. This creates exceptions that the finance team must manually fix to ensure the P&L impact of returns is captured before month-end close.
We plan to offer 'refund at first scan'. Can this cause reconciliation issues?
Yes, this practice can create timing issues if not managed carefully, as the refund is processed before the goods are physically inspected. A robust integration ensures that even after a refund is issued via ZigZag, a subsequent signal from the warehouse (e.g. 'item damaged') can still trigger a matching inventory adjustment or write-off in Stokly ERP. This prevents discrepancies between the financial refund and the actual value of the returned stock.