Marketplace growth is outrunning the systems built to record it. Amazon's third-party seller services reached $172.17 billion in 2025, up 10 percent year over year, according to Marketplace Pulse. Third-party sellers now account for the majority of units sold on the platform. For finance and operations leaders, that growth is good news with a catch. The connection between Amazon and the ERP usually holds at low volume and starts to crack at scale.

The common assumption is that a connector solves the problem. Pick a tool, map the fields, switch it on. In practice, the integration that looked fine at 500 orders a month becomes a source of phantom stock and month-end guesswork at 5,000. The failure is rarely the connection itself. It is what the connection chooses to record, and when.

Why marketplace volume exposes weak integration planning

Volume turns small modeling shortcuts into structural problems. At low order counts, a team can paper over gaps with manual journal entries and a reconciliation spreadsheet. Past a few thousand orders a month, that manual work stops scaling and the data stops being trustworthy.

A 2023 Accenture report cited by industry analysts found that more than 55 percent of mid-market ecommerce companies named persistent reconciliation gaps as their biggest challenge after going live on an ERP. The same analysis makes a sharp point. The issue is not the amount of data. It is the accounting model underneath it.

That distinction matters because it changes what readiness means. A team that frames the project as “connect Amazon to NetSuite” will buy a connector and move on. A team that frames it as “represent Amazon's financial and inventory reality inside NetSuite” will ask very different questions before signing anything.

The three blind spots: inventory timing, returns, and finance handoffs

Three operational gaps cause most of the pain. Each is invisible at small scale and expensive at large scale.

Inventory timing and FBA versus FBM drift. Inventory drift happens when FBA and FBM stock are managed as one undifferentiated pool. FBA stock is stored and shipped by Amazon. FBM stock sits in your own warehouse. When inbound shipments, removals, and damaged-stock adjustments do not post back to NetSuite as proper inventory transfers and adjustments, the balance sheet drifts from reality. The most common structural error is running both fulfillment models against a shared inventory count. The result is phantom availability, overselling, and a slow decline in Amazon seller metrics as cancellations rise. One brand cut cancellations and lifted its seller rating within 90 days simply by making NetSuite the master for FBM quantity and untangling the sync logic.

Returns and reimbursements that never close the loop. Returns break the link between an order, its settlement, and its payout. Lost, damaged, or adjusted FBA inventory often misses reimbursement or settles in a different reporting period than the original sale. Cancellations and partial refunds sever the connection between an FBM order and the money that eventually lands in the bank. Amazon provides reports but leaves reconciliation to the seller. If returns are not modeled as discrete, traceable events, they surface later as unexplained variances that finance has to reverse-engineer.

Finance handoffs and the settlement gap. The finance handoff is where most integrations quietly underdeliver. Amazon pays on roughly 14-day settlement cycles, and each cycle bundles sales, refunds, fees, taxes, and retroactive adjustments into a single net deposit. If your books capture that deposit as a summary entry rather than transaction-level records, you cannot verify that the payout matches what Amazon actually owed. When complex movements post only as basic sales deductions, the year-end reconciliation gap can be large enough that businesses spend weeks reconstructing inventory and revenue records a robust integration would have tracked all along.

The reconciliation tax: what unclear integration actually costs

The reconciliation tax is the recurring cost of integration that records summaries instead of detail. It shows up as time, as inaccuracy, and as decisions made on numbers no one fully trusts.

Published estimates give a sense of scale. Setup guides report finance teams spending two to three days a month untangling settlement reports, and stock discrepancies driving five-figure annual losses through overselling. Case studies from integration vendors consistently claim that automating Amazon to NetSuite reconciliation cuts manual effort by roughly 50 to 80 percent. Treat vendor figures as directional rather than guaranteed, but the direction is consistent across independent sources.

The deeper cost is strategic. When fees, refunds, and adjustments are buried in a catch-all account rather than mapped to the general ledger at the line-item level, SKU-level profitability becomes a guess. You cannot price, advertise, or rationalize a product line confidently if you cannot see its true unit economics. The reconciliation tax is not only the hours lost. It is the decisions you avoid making because the data will not support them.

Why this is an ERP-first problem, not a connector problem

The architecture choice that prevents the reconciliation tax is recording Amazon activity as detailed, transaction-level entries inside the ERP, not as summarized feeds. That is a design decision about your accounting model, made before any tool is selected.

This is where the connector-first habit misleads buyers. Many middleware tools were built for order and inventory sync, and they handle that well. The gap is settlement logic. A tool that moves orders cleanly can still hand NetSuite a lump-sum deposit with no underlying detail. The orders sync. The books still drift.

SAP describes the broader shift in its own integration guidance: point-to-point connections create tangled dependencies that get harder to maintain as the stack grows. The same logic applies to marketplace data. The question is not only whether two systems can talk, but whether the receiving system can hold a complete, auditable version of what happened. That is an ERP-first question. The ERP defines the structure for settlement accounting, multi-location inventory, and SKU-level costing. The integration's job is to feed that structure faithfully.

This framing reflects how connected-operations specialists, including integration platform APPSeCONNECT, increasingly approach marketplace projects. Start from the financial and inventory model the business needs to run on, then choose integration that preserves it, rather than letting the connector's default behavior decide how the books look.

A readiness check before you scale Amazon on NetSuite

Before committing to an integration approach, leaders can pressure-test readiness with a short set of questions. Each one targets a blind spot that only becomes visible at volume.

Are FBA and FBM inventory tracked as separate, clearly mastered pools, or do they share one count? Shared counts create phantom availability.

Does every Amazon transaction, including fees, refunds, and adjustments, post to NetSuite at the line-item level, or as a summary? Summaries make settlements unverifiable.

Can a single bank deposit be tied back to the specific sales, fees, and refunds that make it up? If not, reconciliation stays manual.

Are returns and reimbursements modeled as discrete events that can cross reporting periods? Unmodeled returns become year-end variances.

Can you see profitability by SKU after Amazon fees, or only total channel revenue? Without unit economics, pricing is guesswork.

Does the design hold at ten times current volume, or only at today's order count? Plan for the scale you are growing into.

A team that can answer these confidently is buying integration to execute a model it already understands. A team that cannot is buying a connector and hoping the model sorts itself out. The first approach scales. The second accrues the reconciliation tax.

Where marketplace integration is heading

Marketplace complexity is increasing, not settling down. Sellers now operate across multiple Amazon regions, currencies, and fulfillment models at once, and Amazon continues to evolve its APIs and settlement structures. Each added market multiplies the reconciliation surface. AI-assisted reconciliation tooling is emerging to help match transactions and flag anomalies, but tooling cannot rescue an accounting model that was never designed to hold the detail.

The teams that will scale cleanly on Amazon are the ones that treat integration as an extension of their financial architecture, decided early and deliberately. Marketplace growth rewards operators who can trust their own numbers. That trust is built before the first order syncs, in the choices about what the ERP is asked to record.

About the author: This perspective is contributed by APPSeCONNECT, an integration platform focused on connecting ERPs such as NetSuite, SAP Business One, Microsoft Dynamics 365, Acumatica, and Sage with ecommerce and marketplace channels.