The most common mistake I see in marketplace integration is the assumption that all orders can follow the same path into the ERP. Shopify DTC orders have a clean, predictable structure: customer places order, payment is captured, fulfillment happens, money lands in your bank account. The order and the financial transaction are tightly coupled. When you build a Shopify to NetSuite integration through Celigo, the mapping logic reflects that simplicity. One order becomes one sales order, one fulfillment, one deposit. Clean.
Amazon does not work that way. An Amazon order is not really your order. It is Amazon’s order that happens to involve your product. The customer belongs to Amazon. The fulfillment, if you are using FBA, belongs to Amazon. The financial settlement arrives on Amazon’s schedule, not yours, and it arrives as a batch that bundles sales, returns, fees, adjustments, reimbursements, and promotional charges into a single deposit. There is no one-to-one relationship between an order and a payment anymore.
TikTok Shop introduces its own flavor of complexity. The platform is newer, the settlement structures are still evolving, and the data models change more frequently than established marketplaces. Walmart Marketplace has its own compliance requirements, its own fee structures, and its own timing for settlements.
The point is not that these marketplaces are difficult. The point is that they are different. And different means that a single integration pattern will not serve all of them well.
What Goes Wrong When You Treat Them the Same
I have seen this pattern play out enough times to describe it precisely. A brand launches on Amazon and builds the integration with the same team or the same template that handled their Shopify integration. Orders flow into NetSuite. For the first few weeks, everything looks fine. Revenue is posting, fulfillment records are syncing, and nobody is complaining.
Then the first settlement comes in. Finance opens the bank statement and sees a deposit from Amazon that does not match any combination of orders they can find in NetSuite. That is because the settlement includes deductions for FBA fees, returns that processed after the settlement period opened, advertising charges, and adjustments from three weeks ago that finally cleared. None of these components were broken out in the integration. They arrived as a net number, and now someone on the finance team has to reverse-engineer what Amazon actually paid versus what was sold.
This is not a one-time problem. This happens every settlement cycle. And as Amazon volume grows, the reconciliation effort grows with it. We have worked with brands where the controller was spending an extra two to three days per month just reconciling Amazon settlements, on top of their normal close process.
The same pattern shows up with returns. Amazon processes returns on its own terms and on its own timeline. A customer can return a product weeks after the original order, and the refund shows up in a settlement period that has no obvious connection to the original sale. If the integration does not track return authorizations and map them back to the original transactions in NetSuite, finance is left matching line items manually.
Inventory adds another layer. If you are running FBA alongside your own warehouse or a third-party logistics provider, you now have inventory in multiple locations that need to reconcile. Amazon’s inventory reports do not always align with what NetSuite expects, especially when removals, disposals, and inbound shipments are in transit. The quantity in the FBA warehouse according to Amazon and the quantity in NetSuite according to your integration can drift apart, and that drift creates problems for purchasing, allocation, and financial reporting.
The Real Cost Is Not Technical
What surprises most leaders is that the cost of getting marketplace integration wrong is not primarily a technology cost. It is an operational cost. It shows up in the hours your finance team spends on reconciliation instead of analysis. It shows up in the inventory write-downs that happen because stock levels were inaccurate across channels. It shows up in the delayed close that makes your board deck a week late every quarter.
And it shows up in something harder to measure: decision quality. When marketplace data is unreliable in your ERP, leadership cannot answer basic questions with confidence. What is our true margin on Amazon after fees? Are we profitable on TikTok Shop, or are we subsidizing that channel with DTC margin? Which marketplace should we invest more in, and which one is quietly losing money? These are strategic questions, and they require clean operational data to answer. If the integration is not designed to deliver that data, the strategy is built on estimates.
What Good Marketplace Integration Looks Like
The brands that handle multi-channel well do a few things differently, and none of them are particularly exotic. They just require intentional design.
First, they treat each marketplace as its own integration with its own mapping logic. Amazon orders follow Amazon rules. TikTok Shop orders follow TikTok rules. The flows share infrastructure, but the business logic is channel-specific. This is where working with an experienced Celigo integration partner makes a real difference, because the mapping decisions for each marketplace are informed by patterns observed across hundreds of implementations, not just one brand’s first attempt.
Second, they decompose settlements at the component level. When an Amazon settlement arrives, it does not post as a single net deposit. It breaks out into gross sales, fees by category, returns, adjustments, and reimbursements. Each component posts to the correct account in NetSuite so that finance can reconcile at the line-item level instead of the lump-sum level. This is not easy to build, but it transforms the close process. What used to take days takes hours.
Third, they design for timing differences. Marketplaces do not operate on your accounting calendar. Returns process on their own schedule. Settlements close on their own cycle. Reimbursements can arrive weeks after the event that triggered them. The integration has to account for these timing gaps explicitly, or finance inherits them as manual reconciliation work.
Fourth, they involve finance in the integration design from the beginning. Not after go-live, not during the first close that goes sideways, but at the start. When the controller or accounting manager has input on how data should land in NetSuite, the integration is built to serve the business, not just to move data.
The Channel Mix Is Only Getting More Complex
Every year, brands add channels. What started as Shopify plus Amazon is now Shopify plus Amazon plus TikTok Shop plus Walmart plus Faire plus a wholesale portal. Each one adds operational surface area. Each one introduces its own data structures, its own settlement logic, and its own quirks that the integration layer has to handle.
The brands that scale through this complexity are not the ones with the biggest teams. They are the ones that invested in integration design early and built their operational foundation to handle channel-specific logic without creating channel-specific chaos.
At Hairball, we have built marketplace integrations across every major platform, as a top Celigo implementation partner with more than 550 client implementations behind us. The pattern we see consistently is that the brands which treat each channel as operationally distinct, rather than forcing them all through the same template, are the ones that close cleanly, report accurately, and make confident decisions about where to grow next.
If your marketplace expansion created more work for your finance team than revenue for your business, the integration design is worth revisiting. The channels are not the problem. The plumbing between them and your ERP is.
