Introduction
For most Amazon sellers, the accounting journey follows a predictable arc. It starts with spreadsheets. Then someone recommends Xero or QuickBooks, and things get a little better. For a while, that’s enough.
Then the business grows. Your inventory now sits across multiple locations — an in-house warehouse, active FBA fulfillment centers, and FBA inbound transit. Small-business tools like Xero and QuickBooks lack the native multi-location inventory tracking required to handle this complexity accurately. Add a second marketplace to the mix, and month-end close stretches from two days to two weeks. Your bookkeeper is pulling data manually from Seller Central every quarter to reconcile a spreadsheet that’s never quite right.
That’s when Amazon sellers start asking about ERP.
Third-party sellers now account for 61% of all paid units sold on Amazon (Marketplace Pulse, Q4 2025). Most of them will eventually hit this wall. The question isn’t whether your current system will hold — it’s when it won’t.
This guide covers how Amazon ecommerce accounting works at scale: settlement accounting, multi-location inventory, FIFO costing, SKU profitability, multi-entity reporting. And, critically, what separates a NetSuite integration that produces useful financial data from one that just moves numbers around.
Key Takeaways
Key Takeaways
- Third-party sellers make up 61% of Amazon paid units; 82% use FBA as their primary fulfillment method (Jungle Scout, 2024)
- Recording Amazon’s bank deposit as revenue produces inaccurate books — 14-day settlements aggregate 14+ transaction types that must be recorded individually, on transaction date
- A proper Amazon NetSuite integration posts native transactions (invoices, cash sales, checks, inventory adjustments) so SKU-level profitability flows automatically
- Amazon combined fees can reach 20-30% of selling price (Amazon Seller Central, 2025) — full visibility requires per-SKU cost allocation, not blended channel estimates
- ERP adoption is triggered by operational complexity (multi-entity, inventory scale, audit readiness), not revenue thresholds alone
Why NetSuite for Amazon Sellers?
NetSuite is Oracle’s cloud ERP platform. For Amazon businesses, it replaces spreadsheets and small-business accounting software as the system of record for revenue, multi-location inventory, costs, and multi-entity financials. An Amazon NetSuite integration connects Amazon Seller Central to NetSuite so that every transaction — sales, refunds, fees, reimbursements, inventory adjustments — posts to the correct native NetSuite record automatically.
Why does this matter? Consider what Xero and QuickBooks are designed for. Both are excellent accounting tools for small businesses with clean, simple transaction flows. Amazon isn’t that. Amazon is a settlement system, a fulfillment network, a fee processor, and an advertising platform combined. It generates 14+ transaction types per settlement period, each with a different accounting treatment. Managing financial accounting inside a small-business accounting tool works, but inventory rapidly becomes a big issue.
NetSuite is the ERP most mid-market Amazon sellers land on because it handles what the smaller tools can’t:
- Multi-location inventory — FBA, 3PL, and other locations tracked in one system with real-time COGS. Xero and QuickBooks Online don’t have a notion of inventory locations.
- Multiple costing methods — NetSuite supports FIFO, average cost, standard cost, and lot costing. QuickBooks Online supports FIFO only, with no costing method flexibility as your business structure changes.
- Audit-ready financials — transaction-level records, approval workflows, role-based access controls, and a full audit trail. QuickBooks’ permission model is far more limited.
- Scalable transaction volume — no performance degradation as order volume grows. High-volume sellers routinely hit QuickBooks Online’s transaction limits and report degraded performance at scale.
- Multi-entity consolidation — subsidiaries, intercompany eliminations, currency conversion, all in one instance. QuickBooks requires a separate company file per entity with no native consolidation.
That’s why the ERP and the integration layer matter together. Entriwise is built specifically to connect Amazon Seller Central to NetSuite in a way that uses all of these capabilities — not just the accounting basics that QuickBooks and NetSuite share.
Most Amazon businesses don’t move to NetSuite because they hit a revenue target. They move when the accounting team can no longer keep up with real operational complexity.
Common triggers include:
- Inventory spread across FBA, 3PL, and in-house locations with reconciliation gaps
- SKU-level margin reporting that needs item-level fee and cost allocation
- Month-end close slipping because Amazon settlements and inventory adjustments are still manual
- International expansion with multi-currency and VAT requirements
- Preparing for audit, investor due diligence, or acquisition
- Need for ERP-level workflows, approval controls, and permissions
- Multiple legal entities that need consolidated reporting and intercompany eliminations
A business with $3 million in revenue but three entities and UK operations may need NetSuite before a $15 million single-entity domestic business does. It comes down to what the accounting system has to track, not how much revenue flows through it.
The Hidden Costs of Bad Amazon Accounting
What actually happens when you record Amazon’s bank deposit as revenue? Or when your integration posts broad summaries instead of native transactions? The problems aren’t always obvious, and they tend to compound.
1. You Can’t See Which Products Are Profitable
Even if Amazon sales map to inventory items, broad fee summaries leave your SKU profitability report incomplete. You know channel-level revenue and gross margin, but you don’t know whether your top-selling ASIN is actually making money or losing it after deductions. A product with a 15% referral fee, $9 in FBA fulfillment, $3 in storage, and a 12% return rate might look like a 35% margin item on the surface — until you allocate all the costs accurately.
2. Complex Multi-Location Inventory Valuations Get Broken
Amazon sellers hold inventory across multiple Amazon fulfillment regions, local warehouses, and sometimes across multiple countries. If complex FBA or FBM inventory movements don’t post as proper InventoryTransfers and InventoryAdjustments (beyond basic sales deductions), NetSuite’s balance sheet drifts from reality. At year end, the reconciliation gap can be significant. We’ve seen businesses spend weeks at year end reconstructing inventory records that a robust integration would track accurately.
3. You Can’t Reconcile to the Penny
Amazon pays through 14-day settlement periods. Each period aggregates sales, refunds, fees, and adjustments into a single net deposit. If your books show summary entries rather than transaction-date records, you can’t verify that the deposit matches what Amazon actually owed you. Settlement reconciliation — confirming that the sum of all transactions in a period nets exactly to the payout — is only possible when each transaction is recorded individually.
4. Month-End Close Becomes a Manual Process
Without comprehensive fee mapping and daily transaction posting, every month-end requires manual work: pulling data from Seller Central to verify missing adjustments, reconciling lumped fee categories, and manually adjusting returns or discrepancies. At $5 million in revenue, that’s manageable. At $20 million across three entities, it’s a full-time job for a two-person accounting team — and it still won’t be as accurate as automated posting.
5. You’re Not Ready for a Raise, a Sale, or an Audit
Buyers, investors, and auditors want accrual-based financials with transaction-level detail. Net-deposit accounting or basic summary reports don’t meet that bar. Rebuilding clean books from years of summary data is expensive, slow, and sometimes impossible. The cost of fixing bad accounting at acquisition time often exceeds the cost of doing it right from the start.
Amazon Settlement Accounting Explained
The most common Amazon accounting mistake is treating the payout as revenue. It overstates revenue in months with low refunds and understates it when large refund batches hit. Neither is accurate, and both make financial statements unreliable for business decisions.
Amazon functions like a clearing account — it collects gross revenue, deducts every fee and refund, then disburses the net balance every 14 days. During each settlement period, Amazon records:
- Product sales and shipping income
- Referral fees, FBA fulfillment fees, storage fees
- Advertising charges and coupon fees
- Customer refunds and refund administration fees
- Reimbursements for lost or damaged inventory
- Inventory adjustments and disposal events
- Inbound shipment charges
- Subscription fees and Vine fees
Correct settlement accounting records each event as its own accounting entry, on its transaction date — not the payout date:
| Event | Accounting Entry |
|---|---|
| Product sale | Revenue |
| Referral fee | Expense |
| FBA fulfillment fee | Expense |
| Storage fee | Expense |
| Advertising | Expense |
| Customer refund | Revenue reversal |
| Reimbursement | Expense reversal (VendorCredit) |
| Inventory adjustment | Inventory / COGS adjustment |
| Settlement payout | Transfer to bank |
When all entries are recorded correctly, the transactions in a settlement period net exactly to the payout deposit. That reconciliation — Amazon settlement reconciliation — is what confirms the books are right and provides an auditable trail.
Here is an industry secret: the vast majority of Amazon NetSuite integrations simply dump order and fee data into the ERP without ever verifying if that data matches the actual cash Amazon deposited. If the transactions are off by a few dollars (or a few thousand dollars), you won’t know until you try to close the books manually. Entriwise is uniquely built to automatically reconcile to the penny. It posts each Amazon event on its transaction date, handles the settlement-period timing, and programmatically guarantees that the transactions inside NetSuite sum perfectly to the bank deposit.
Amazon referral fees range from 5% to 45% depending on category, with most categories at 15%. Add FBA fulfillment fees, storage, and advertising, and the effective Amazon take rate commonly reaches 20-30% of selling price (Amazon Seller Central, 2025). On $5 million in gross sales, that’s $1-1.5 million in Amazon-related costs. Categorizing those correctly isn’t optional — it’s the difference between knowing your margins and guessing them.
How Amazon Seller Central Connects to NetSuite
A proper Amazon NetSuite integration turns Amazon’s settlement flat file into native NetSuite transactions. The workflow is straightforward in concept: parse and normalize the Amazon data, map each event to the right NetSuite record, and post it via the NetSuite API.
The transaction mapping is more granular than most sellers realize. Take FBA inventory events alone: when inventory is found or reimbursed, that’s an InventoryAdjustment (positive quantity). When inventory is lost or damaged, that’s an InventoryAdjustment (negative quantity). When a shipment arrives at an FBA fulfillment center, that’s an InventoryTransfer that moves stock from your warehouse or 3PL to Amazon’s network. Each of these hits the balance sheet and income statement differently — and only works correctly when it posts as the right transaction type.
Fee handling works the same way. Referral fees, FBA fulfillment fees, storage fees, and advertising spend each post as Check transactions against the appropriate expense accounts. Reimbursements post as VendorCredit + Deposit pairs — a credit to offset the original expense, plus a deposit to record the cash received. The architecture mirrors the underlying economics, not just the cash flow.
Why does this matter at scale? Amazon’s third-party seller services generated $156.15 billion in full-year 2024 revenue (Amazon 2024 Annual Report, February 2025). For businesses running at meaningful scale within that ecosystem, the accounting architecture behind the connector determines whether financial reporting is useful or not. Get the mapping right and reporting runs itself. Get it wrong and you’ll spend the last week of every month manually pulling data from Seller Central to reconcile books that were never accurate.
Entriwise is a native NetSuite connector that implements exactly this mapping — native transactions for every Amazon event, individual fee lines per category, settlement-date posting, and automated COGS recognition. It also handles the edge cases that catch most integrations: FBA inventory adjustments post as proper InventoryAdjustments, bundle SKUs expand into their component items before posting to NetSuite, and multi-entity sellers can route each marketplace’s transactions to the correct subsidiary automatically. See the NetSuite integration platform for details.
Item Mapping and Error Recovery
Amazon sellers often discover that the hard part is not just syncing orders, but mapping the right Amazon product to the right NetSuite item. That becomes especially important when Amazon SKUs, pack sizes, and bundle structures do not match the accounting structure in NetSuite.
Entriwise is built for explicit mapping rather than one-size-fits-all SKU assumptions:
- An Amazon SKU can map to a different NetSuite SKU.
- One NetSuite item can map to multiple Amazon listings or marketplace SKUs.
- Pack SKUs, such as a 10-pack, can use inventory multipliers in the mapping.
- Bundle-style sales can be split into component items with the sales price allocated across those components.
For teams that need custom logic, pre-map and post-map hooks can be added, but that is a more technical implementation path than a point-and-click UI setting today. The platform also supports multiple connections and paginated imports when the source system requires it.
Just as important, failed records do not disappear into the pipeline. Entriwise can retry errors, tag exceptions, and help resolve them, and it checks imported data to make sure the accounting result is actually correct. For Amazon settlement imports, it also checks reconciliation so the imported activity ties back to the expected payout.
Because Entriwise keeps its own reconciliation record for imported activity, mismatches can be corrected in Entriwise itself. If something was imported with the wrong amount or needs to be removed, it can be edited, deleted, and re-imported without forcing a more technical cleanup process directly in NetSuite.
Convention Over Configuration
There’s a well-known hurdle when moving to an ERP: the implementation timeline and the associated technical complexity.
Many Amazon to NetSuite connectors are extremely technical blank slates. To set them up correctly, map the complex flow of FBA and FBM inventory, and configure hundreds of obscure Amazon fee codes, you almost always need to involve an expensive NetSuite consultant billing by the hour. The setup process can easily drag out for weeks or months.
Entriwise relies on a convention over configuration philosophy. The system comes pre-engineered to understand the exact nuances of Amazon’s financial architecture out of the box, hiding the daunting complexity of Amazon’s transaction codes and settlement logic from the user. Because it relies on highly sensible defaults tailored exactly for Amazon FBA and multi-channel businesses, even non-technical people can get started with Entriwise in less than an hour.
This extreme user-friendliness isn’t just about convenience—it saves NetSuite users countless hours in training and routinely saves teams thousands of dollars in initial implementation costs by eliminating the need for billable external consultants to configure basic accounting logic.
Financial Accounting vs. Order Management
While most sellers focus initially on getting Amazon payouts properly accounted for, a robust integration must often handle three distinct workflows simultaneously: financial accounting, inventory tracking, and—for Seller Fulfilled (FBM) orders—order management.
For FBA sellers, Amazon handles the fulfillment. The integration’s job is purely financial and inventory-related: record the sale, deduct the inventory, post the COGS, and reconcile the settlement.
But if you also fulfill orders yourself (FBM), your integration needs to bring those orders into NetSuite in real time so your warehouse team can pick, pack, and ship them. This creates a standard NetSuite workflow: Sales Order → Item Fulfillment → Invoice.
Here is where most integrations fail. Doing basic API order syncing for fulfillment is relatively easy. Doing batch financial accounting is slightly harder. A truly exceptional integration does both financial and inventory accounting AND real-time order management for seller-fulfilled orders (if required), ensuring that both workflows function flawlessly together.
Making sure real-time order creation doesn’t double-count revenue or inventory when the bi-weekly Amazon settlement finally drops, while simultaneously producing perfectly reconciled financial imports, is the most difficult—yet most important—technical challenge to achieve in ecommerce ERP integration. Getting this wrong leads to duplicate sales, broken inventory counts, and settlements that never tie out.
The Power of Native NetSuite Transactions
Here’s something most Amazon sellers learn too late: the way an integration posts data to NetSuite matters as much as the data itself.
To get the full value out of NetSuite, your integration must post native NetSuite transactions for every Amazon event. While most NetSuite integrations handle basic order syncing and inventory tracking, many still pull simple summaries for Amazon fees and returns that fail to allocate costs accurately. If your integration doesn’t map every single fee, refund, and adjustment granularly, you miss out on true SKU profitability. You’ve moved money into NetSuite without capturing the full operational cost behind each sale.
Entriwise is built on this principle, posting proper native NetSuite transactions for every corresponding Amazon event:
| Amazon Event | NetSuite Transaction | Why It Matters |
|---|---|---|
| Product sale | CashSale | Links to inventory item; triggers automatic COGS recognition |
| Customer refund | CashRefund | Reverses the original income; restores inventory if applicable |
| FBA fee / referral fee | Check | Posts to expense account; visible in P&L by fee type |
| Advertising spend | Check | Categorized as marketing expense; trackable by campaign |
| Inventory reimbursement | VendorCredit + Deposit | Treated as expense reversal, not miscellaneous income |
| FBA inbound shipment | InventoryTransfer | Moves inventory between locations; updates cost layers |
| FBA lost / damaged inventory | InventoryAdjustment | Adjusts quantity on hand; hits COGS correctly |
| Settlement payout | Bank Deposit | Reconciles against the sum of all prior entries |
When Entriwise records the Amazon fee and return layer at the SKU level and NetSuite holds the related sales and COGS postings, the combined system can produce fully-burdened SKU-level profitability reports and track operations automatically. Without this level of granular mapping, the cash reconciliation still works — but the deeper business intelligence is gone.
According to Jungle Scout’s 2025 State of the Amazon Seller report, 57% of Amazon sellers achieve profit margins above 10% (Jungle Scout, 2025). Getting to that kind of margin visibility requires transaction-level accounting, not summary posting.
Summarizing Transactions to Save NetSuite Billing Lines
While posting native NetSuite transactions is crucial for accurate SKU-level reporting and automated COGS, there is a catch for high-volume Amazon sellers: NetSuite often licenses by service tier, which includes strict monthly limits on transaction lines.
If an Amazon seller processes 10,000 orders a day, posting 10,000 individual CashSales to NetSuite daily will quickly blow through standard API and transaction line limits, forcing an expensive NetSuite tier upgrade.
The solution is summarizing transactions by date. A well-architected connector doesn’t post every single individual Amazon order. Instead, it aggregates transactions by SKU and by date, posting a single consolidated CashSale for each SKU sold on a specific day.
Crucially, this aggregation can be applied to both FBA and Seller Fulfilled (FBM) orders. Alternatively, if your business uses NetSuite to handle seller fulfillment directly (via the standard Sales Order to Item Fulfillment workflow), you can choose to summarize only your FBA transactions while letting Seller Fulfilled orders post individually.
For example, if you sell 500 units of a specific ASIN in one day, the integration creates one CashSale line with a quantity of 500, rather than 500 separate CashSales for a quantity of 1.
That same pattern lets Entriwise run daily imports in summarized form while still preserving the underlying inventory detail through item-level postings, location-level transfers, and inventory adjustments. For high-volume FBA sellers, that is especially useful because it keeps NetSuite billing lines down without sacrificing cost layers or stock visibility.
This approach preserves everything that makes native transactions valuable:
- Accurate SKU-level profitability and fee allocation
- Automatic FIFO COGS recognition
- Amazon settlement reconciliation to the penny
Most importantly, it reduces the transaction volume pushed into NetSuite by up to 99%. This saves NetSuite billing lines, avoids forced tier upgrades, and keeps your system performing smoothly—all without sacrificing any financial visibility. Entriwise automatically summarizes Amazon transactions by date and SKU specifically to solve this problem for high-volume enterprise sellers.
Inventory, COGS, and FIFO Costing
Inventory is typically the largest asset on an ecommerce balance sheet. COGS is typically the largest expense on the income statement. If either is wrong, the financial statements are wrong — and decisions made from those statements follow.
Amazon sellers—whether fully FBA, FBM (Seller Fulfilled), or a hybrid—hold inventory across multiple locations at once:
- Amazon FBA fulfillment centers (often multiple regions)
- Third-party logistics (3PL) warehouses
- Own warehouse or distribution center
- Inventory in transit (from manufacturer or between locations)
- Returns processing
- Unsellable inventory pools
Most small-business accounting tools handle one or two locations at most. Managing both FBA and FBM inventory across five or six locations — with accurate cost layers at each one — is where they break down. You end up estimating inventory values rather than calculating them, which means your COGS is also an estimate. And estimated COGS means estimated margins.
In our experience, this is where the gap between small-business accounting and ERP becomes most visible in day-to-day operations. It’s not the chart of accounts or the reporting templates. It’s the inventory valuation — specifically, whether the system can track movement across all locations and recognize cost at point of sale automatically.
IHL Group’s 2023 Inventory Distortion Study found that global inventory inaccuracies cost retailers $1.77 trillion annually, equivalent to 7.2% of global retail sales (IHL Group, 2023). For ecommerce businesses, the accounting dimension is equally significant: incorrect inventory values produce incorrect COGS, which produces incorrect gross margin, which produces incorrect decisions about what to restock and what to cut.
NetSuite tracks inventory across all locations with real-time COGS recognition at point of sale. When a unit sells, the system pulls the correct cost layer and posts COGS automatically. No manual adjustments, no month-end estimates. QuickBooks Online has no native support for tracking inventory separately by FBA region, 3PL, or warehouse — it treats all inventory as a single pool, which means COGS is averaged across locations rather than calculated from the actual cost layer at the location where the unit shipped from.
Entriwise feeds this correctly for both fulfillment models. For FBA, inbound receipts post as NetSuite InventoryTransfers that move stock into the right fulfillment location with the right cost. For FBM, the integration manages seller-fulfilled location stock and ties directly into correct inventory nodes. When a unit sells through either channel, NetSuite picks up the cost from that specific location’s FIFO layer automatically.
That inventory foundation is what FIFO depends on: clean receipts, correct location balances, and inventory adjustments that keep cost layers aligned with reality.
FIFO Costing for FBA and FBM Sellers
Both QuickBooks and NetSuite support FIFO. The difference shows up in complex environments — multiple locations, frequent cost changes, high volume — where ERP-level controls become necessary.
What Is FIFO and Why Does It Matter for Amazon Sellers?
FIFO (First In, First Out) assigns cost based on when inventory was received. The oldest units are expensed as COGS first; ending inventory is valued at the most recent purchase prices.
Under FIFO:
- Each inventory receipt creates a cost layer at the unit cost on that date.
- When a unit sells, the system pulls cost from the oldest open cost layer.
- Ending inventory reflects the most recent purchase prices.
FIFO is accepted under both GAAP and IFRS and is standard in ecommerce and retail. The principle is simple. The challenge is keeping the underlying data clean enough for the costing to stay accurate — which is harder than it sounds when you’re managing inventory across six FBA regions, a 3PL, and inbound shipments from three manufacturers.
When Does FIFO Break Down?
FIFO only stays accurate if:
- Inventory receipts are posted correctly and on time
- Opening inventory balances are right
- Amazon inventory adjustments sync into the accounting system
- Negative inventory doesn’t appear in the system
Incorrect receipts produce incorrect cost layers. Incorrect cost layers produce incorrect COGS — regardless of which costing method you’ve selected. This is why integration accuracy and inventory setup matter so much when implementing NetSuite for Amazon FBA and FBM accounting. The costing method is only as good as the data feeding it.
What we’ve found is that most FIFO accuracy problems in NetSuite trace back to the integration, not the ERP itself. If FBA inbound shipments don’t post as InventoryTransfers, or if FBM inventory adjustments are missed, the cost layers in each fulfillment region never get established correctly. Fix the integration data, and the FIFO math takes care of itself.
This is also where QuickBooks reaches a structural limit, not just a feature gap. QuickBooks Online’s FIFO implementation runs against a single inventory pool. It can’t assign cost layers to specific locations, which means it can’t give you accurate COGS when the same SKU sits at three FBA regions with different landed costs. NetSuite’s multi-location costing can — and Entriwise is built to feed it correctly from day one.
SKU-Level Profitability in NetSuite
Do you actually know which of your SKUs are profitable? Not blended channel margin — true net margin per product, after every Amazon cost is allocated?
Most ecommerce businesses think they do. In practice, most are working from gross margin estimates that don’t fully allocate referral fees, FBA fulfillment fees, storage costs, and return rates at the product level. The result is a P&L that looks healthy overall while a portion of the catalog quietly loses money on every unit shipped.
A proper SKU profitability report in NetSuite includes:
- Revenue per SKU
- Cost of goods sold per SKU (FIFO)
- Amazon referral fee per SKU
- FBA fulfillment fee per SKU
- Storage fee allocation per SKU
- Advertising spend per SKU
- Refund rate and refund cost per SKU
- Net margin per SKU
82% of Amazon sellers use FBA as their primary fulfillment method (Jungle Scout, 2024), which means FBA fees are a line item for the vast majority of sellers. Those fees vary by product dimensions and weight. A large, heavy item with a 15% referral fee plus $9 in FBA fulfillment, $2 in monthly storage, and a $6 advertising cost per unit sold looks very different from a lightweight item at the same selling price — even if gross margin percentages look similar on the surface.
This level of visibility is hard to produce in QuickBooks or Xero. QuickBooks doesn’t have a native concept of “fee expense per SKU” — it records fees at the account level, not the item level. NetSuite is also not enough by itself for Amazon fee attribution: it can hold the sales and COGS data, but it does not natively attach Amazon commissions, FBA fees, storage, and advertising spend to each SKU in a way that produces reliable product margin.
Entriwise solves that gap by recording daily Amazon SKU sales and the associated fees at the SKU level, then combining that information with NetSuite COGS data. That is what produces true per-SKU profitability: revenue, FIFO COGS, Amazon fee allocation, advertising spend when connected, and return costs all tied back to the product.
See profitability analytics for how the report works in practice.
Multi-Entity Ecommerce Accounting
Scaling beyond a single Amazon US account usually means adding legal entities. A UK or EU marketplace requires a local entity. A brand IP holding structure adds another. Wholesale and B2B operations often run under different entities than DTC. Manufacturing may sit in a separate company entirely.
Common multi-entity structures for Amazon businesses include:
- US operating entity + UK or EU subsidiaries
- Parent holding company + operating subsidiaries
- Brand IP entity (separate from the operating business)
- Wholesale or B2B entity
- Manufacturing or sourcing entity
These entities share inventory and costs but need separate books. They may also:
- Transfer inventory between companies at arm’s-length prices
- Operate in multiple currencies with proper foreign exchange accounting
- Produce consolidated financial statements for ownership or investors
- Handle intercompany eliminations so internal transactions don’t inflate revenues
- Comply with VAT (EU and UK) and US sales tax under separate registrations
Managing this in separate accounting files — a separate QuickBooks instance for the US entity, another for the UK, another for EU — produces a financial picture that’s always six weeks behind. There’s no native consolidation in QuickBooks. Someone has to export each entity’s P&L, combine them in a spreadsheet, and manually eliminate intercompany transactions. Currency conversion is manual too. At two entities, it’s tedious. At four, it’s a month-end bottleneck that delays reporting by weeks.
NetSuite runs all subsidiaries in a single instance. Month-end consolidation that would take days in separate files runs automatically, with currency conversion and intercompany eliminations handled by the system.
Entriwise routes each Amazon marketplace’s transactions to the correct subsidiary in NetSuite automatically. Amazon US posts to the US entity. Amazon UK posts to the UK subsidiary. Intercompany inventory transfers — when US inventory ships to the UK entity — get recorded as NetSuite intercompany transactions with proper arm’s-length pricing. The consolidation just works.
78.6% of ERP implementations in 2024 used cloud-based deployment, up from 64.5% the year before, with average implementation timelines dropping from 15.5 months to 9 months (Panorama Consulting Group, 2024). Multi-entity ecommerce accounting is one of the primary drivers pushing businesses toward cloud ERP. The alternative doesn’t scale.
A Tale of Two Sellers
Let’s see how these differences play out in practice. Consider two Amazon sellers — both doing $8 million a year, both running FBA, both with a UK entity added eighteen months ago.
Settlement Sam
Sam’s team built a basic Amazon-NetSuite connection. It posts a bi-weekly summary when the settlement report arrives: a basic deposit with a few lines for fee categories. The bank reconciles. The books close.
- The P&L: Sam sees Amazon revenue and a blended fee line. He can’t break out which fee types are growing, and he can’t see margin by product.
- The inventory: FBA inbound shipments don’t post as InventoryTransfers, so NetSuite’s location-level inventory is always out of sync with Seller Central. Every quarter, his team spends a week reconciling the gap manually.
- The UK entity: Sam’s UK subsidiary runs in a separate QuickBooks file. Intercompany inventory transfers are tracked in a spreadsheet. Month-end consolidation takes five days.
- The problem: Sam’s top SKU looks like a 28% margin product. He’s been restocking it aggressively for two years. When his accountant finally allocates all FBA fees, storage, and return costs at the product level, the real margin is 11%.
Native-Transaction Natalie
Natalie uses Entriwise to connect Amazon Seller Central to NetSuite. Every Amazon event posts as the correct native NetSuite transaction — no broad summaries, no manual mapping.
- The P&L: Every sale posts as a CashSale tied to an inventory item. Every fee category — referral, FBA fulfillment, storage, advertising — posts as a Check against its own expense account. She runs a NetSuite saved search filtered by item and sees gross margin, each fee type, and net margin per SKU on demand. No spreadsheet, no month-end data pull.
- The inventory: Entriwise posts FBA inbound shipments as InventoryTransfers that move stock into the correct NetSuite location with the right cost layer. Lost and damaged FBA inventory posts as InventoryAdjustments that hit COGS correctly. NetSuite’s location-level inventory matches Seller Central automatically.
- The UK entity: Natalie’s US and UK entities both run in the same NetSuite instance. Entriwise routes Amazon US transactions to the US subsidiary and Amazon UK transactions to the UK subsidiary. Month-end consolidation — currency conversion, intercompany eliminations, consolidated P&L — runs automatically. It takes half a day instead of five.
- The result: Natalie’s SKU profitability report shows two products losing money after full cost allocation — something that never surfaced in Sam’s blended fee line. She discontinues them and reallocates ad spend to three high-margin products. Over the next year, her blended net margin improves by 4 percentage points on the same revenue base.
The difference isn’t the ERP. Both sellers have NetSuite. The difference is whether the integration uses what NetSuite actually offers — native transactions, multi-location inventory, multi-entity routing — or just pushes numbers into it the same way you’d push them into QuickBooks.
Conclusion
Amazon accounting is complex because Amazon isn’t just a sales channel. It’s a settlement system, a fulfillment network, a fee processor, and an advertising platform combined — all generating separate transaction types that require separate accounting treatments.
As Amazon businesses grow, accounting shifts from bookkeeping to systems architecture. Integrations, inventory controls, settlement reconciliation, and multi-entity financial reporting all have to work together for the numbers to mean anything. The ERP handles the architecture. The integration determines whether the data inside it is trustworthy.
NetSuite is the ERP most mid-market Amazon sellers land on at scale because it handles what smaller tools can’t:
- Amazon settlement accounting with full transaction-level detail
- Multi-channel sales across Amazon, Shopify, Walmart, and others
- Multi-entity structures with automatic intercompany eliminations
- Multi-location inventory with FIFO costing for FBA and FBM
- SKU-level profitability reporting across all cost types
- Consolidated financial statements across subsidiaries
- Audit-ready financials and ERP-level workflow controls
But the ERP is only part of the answer. How Amazon integrates into it — and what transactions the integration creates — determines whether the financial data is actually useful.
Ready to connect Amazon Seller Central to NetSuite the right way? Explore the Entriwise Amazon NetSuite integration to see how native transaction posting, settlement reconciliation, and SKU-level profitability work in practice. If you are standardizing more than one sales channel on the same ERP stack, continue with Shopify NetSuite integration and TikTok Shop NetSuite integration.
Frequently Asked Questions
How does Amazon settlement accounting work in NetSuite?
Amazon settlement accounting in NetSuite maps each Amazon transaction to its correct accounting entry: sales post as Cash Sales, fees post as Checks, refunds post as Cash Refunds, and the settlement payout posts as a Bank Deposit. The sum of all entries for a settlement period nets exactly to the bank deposit. That reconciliation confirms the accounting is accurate and provides the transaction-level audit trail needed for financial statements. Recording the deposit directly as revenue skips this structure and produces inaccurate books.
Can NetSuite track SKU profitability for Amazon sellers?
Not by itself. NetSuite can hold the accounting data and COGS, but it does not natively assign Amazon fees like referral commissions, FBA fulfillment, storage, or advertising to the correct SKU. Entriwise fills that gap by recording daily Amazon SKU sales and fee activity, then combining that data with NetSuite COGS so sellers can see true net margin per SKU instead of a blended channel estimate. Most sellers find meaningful margin surprises when they see the fully-burdened per-SKU data for the first time.
When should an Amazon seller move from QuickBooks to NetSuite?
The decision comes down to complexity, not revenue. Common triggers include operating holding large inventory balances across multiple locations or 3PLs, needing SKU-level profitability reporting, preparing for audit or acquisition, having multiple legal entities, expanding internationally.
What does an Amazon NetSuite connector do?
An Amazon NetSuite connector pulls transaction data from Amazon Seller Central and posts it into NetSuite as native transactions. A well-built integration maps product sales to Cash Sales, fees to Check records, refunds to Cash Refunds, inventory movements to Inventory Transfers, and settlement payouts to Bank Deposits. It also handles inventory item matching so COGS posts automatically at the point of sale. The integration replaces manual data entry, eliminates settlement reconciliation work, and keeps inventory valuation current in real time.