# Cross-system data cleanup Source: > Product attributes, order metadata, and operational signals exist in your stack. They just do not reach the systems that need them. We map the flow, fix the integration code, and stop the manual re-entry. ## The problem The data exists in your stack. It is not reaching the system that needs it. DIMs you maintain in NetSuite never reach ShipStation. Weights you update in your product master do not propagate. Custom fields die at the integration boundary. Operators retype the same data into the next system because the integration dropped it. One recent audit: 89.9% of active SKUs had accurate dimensions in NetSuite. 0.2% of those dims reached ShipStation. The Celigo flow at the boundary had a complete items sub-mapping but no dimensions sub-mapping — a four-row mapping gap was breaking rate shopping on every multi-item domestic shipment. - **Fields drop in transit**: dimensions in NetSuite never reach ShipStation; weight updates in the product master do not propagate; custom fields die at the Celigo or Cart Rover boundary. - **Drift between systems**: inventory in NetSuite says one thing, ShipStation says another, the warehouse says a third. Same SKU, three numbers, no agreement on which is correct. - **Manual re-entry fills the gaps**: operators type the same dims, weights, addresses, and tags into ShipStation, the OMS, and the spreadsheet. Errors compound at every touch. - **Silent transformation errors**: a custom field maps to the wrong target. A tag gets stripped. A tracking number propagates to all five boxes instead of one. Nothing crashes; the data lands wrong. - **Automation fires on bad data**: carrier-selection rules use a default weight because the real one never arrived. VIP rules miss customers because the tag did not propagate. The rules are fine; the inputs are not. - **Integration errors go unalerted**: one recent audit found 33 open Celigo errors across 7 flows with no alerting wired up. Orders silently stuck in the pipeline; problems surface reactively when a customer calls. - **Surprises land downstream**: DIM-weight invoice surcharges, address-correction fees, lost-package liability when the carrier saw the wrong tracking. The cost shows up weeks after the data error. ## The solution We trace every product attribute, order field, customer field, and tag from source to every downstream system. We name what drops, where, and why. Then we fix the Celigo flows, the Cart Rover scripts, the native connectors, and the custom code so the field reaches the right destination as the right type. - **Field-level audit** across every integration; one row per field per system, with status. - **Integration code fixes** in Celigo flows, custom Cart Rover scripts, native connectors, and bespoke ETL. - **Source-of-truth alignment**: one system owns each piece of data; the others subscribe. - **DIM and weight propagation**: dimensions in your product master reach ShipStation rate-shop and pack flows within minutes. - **Tag and metadata flow**: customer tags, channel tags, VIP markers, gift flags survive the integration boundary so downstream automation rules fire on real signals. - **Reconciliation reports**: daily diff between what each system says and what the source-of-truth says. Drift surfaces in the report, not in a customer-service ticket. ## The outcome Operators stop typing the same data twice. Reports across systems agree because they pull from one source. Automation rules fire on data that is actually correct. DIM-weight invoice surprises, address-correction fees, and oversells drop because the data the system acted on was right. ## Frequently asked questions **Is this just an audit, or do you fix the integrations?** Both. The audit is week one; the field-level fixes start week two and ship to staging before they touch production. You can buy only the audit if you want to do the fixes yourself, but most clients want both. **Do you replace Celigo or our custom integrations?** No. We fix what is there. Replacing the integration platform is a separate scope you would not buy from us first. Most data-flow problems are mapping bugs and unhandled edge cases inside the existing flows, not platform limits. **What if our source-of-truth conflict is political, not technical?** Most of them are. Part of the audit deliverable is naming which system should own each piece of data and why, with the trade-offs surfaced. We help you make the call; we do not make it for you. **How quickly do operators stop the manual re-entry?** Per field. As each fix ships, the corresponding manual step disappears. Most clients see operators stop typing dims into ShipStation in week three or four; tags follow soon after; full elimination depends on how many fields are broken. **What about data that is genuinely missing, not just dropped in transit?** We name it in the audit and propose a fill plan. Sometimes that is a one-time backfill (weights for 5,000 SKUs from the supplier spec sheet), sometimes a process change (require dims at SKU creation), sometimes a measurement project (cubiscan run for the existing catalogue). ## Related - [/solutions/inventory](https://www.gotopo.com/solutions/inventory) - [/solutions/automation-rules](https://www.gotopo.com/solutions/automation-rules) - [/solutions/rate-shopping](https://www.gotopo.com/solutions/rate-shopping)