Switching the tool that posts your marketplace settlements into your accounting system is a bigger operation than switching almost any other piece of software in an ecommerce business, because the thing you are replacing has been writing to your general ledger. Six things break predictably. All six are manageable if you plan the cutover, and all six are expensive if you discover them in February while preparing a tax return.
1. The seam at the cutover date
Marketplace settlement periods do not respect month boundaries. Amazon settles on a rolling two week cycle, and a settlement that opens on the 26th and closes on the 9th belongs partly to one month and partly to the next.
Switch tools mid-settlement and you get one of two failures. Either both tools post the overlapping period, and your revenue is double counted, or neither does, and you have a gap. Both are easy to miss because the amounts look plausible.
The fix is to cut over on a settlement boundary rather than a calendar boundary. Let the outgoing tool finish the settlement it started, note the exact settlement ID and its closing date, and start the new tool on the next one. Write the boundary down. You will need it again when someone questions the transition month.
2. Chart of accounts mapping does not carry across
Every sync tool has its own opinion about which accounts marketplace components should hit. One posts FBA fulfillment fees to a single fulfillment expense account. Another splits inbound and outbound. One treats promotional rebates as contra revenue. Another books them as a marketing expense.
Neither is wrong. But if you change tools without deliberately rebuilding the mapping, your year over year comparisons stop meaning anything. Marketing spend appears to jump 40 percent in March because a category moved, not because anything changed in the business.
Export the outgoing tool’s mapping before you cancel it. Most sellers cancel first, then discover the configuration is gone along with the subscription.
3. Historical depth is capped, and the caps differ
Backfilling history is where switches most often stall. Sync tools limit how far back they will pull, and the limit is usually tied to the plan you are paying for rather than to what the marketplace holds.
A2X publishes this plainly on its pricing page: three months of history on the entry plan, twelve on the next, twenty four above that, and maximum available history on premium plans. It also notes that for Amazon Pay specifically, a maximum of 24 months of historical data is available regardless. The practical workaround, which A2X documents, is to subscribe to a higher plan temporarily to pull the history and then move down.
Check this before you migrate, not after. If you need three years of history and your new tool will give you twelve months, you need a different plan, a different tool, or a decision to leave the old years where they are.
4. Inventory valuation jumps at the boundary
If both the old and new tools calculate cost of goods sold, they may not calculate it the same way. Different treatment of landed cost, different handling of inbound freight, different averaging methods, and different timing for when a unit moves from asset to expense all produce different numbers from identical underlying data.
The result is a step change in your inventory asset balance on the cutover date that has no operational cause. Your accountant will ask about it. You need an answer better than the tool changed.
Take a physical inventory count at the cutover, value it deliberately at landed cost, and enter that as the opening position in the new system. It converts an unexplained jump into a documented adjustment, which is a completely different conversation.
5. Reserves and in-transit amounts fall between the systems
Marketplaces hold back funds. Amazon maintains a reserve, and payouts you have earned but not received sit in a state that is neither cash nor unearned. A well configured sync tool carries this as a receivable or a clearing account.
When you switch, the old tool’s clearing account balance has to be deliberately transferred to the new tool’s equivalent. Left alone, it sits there as an orphaned balance that nobody can explain and nobody wants to write off, and it will still be there three years later.
6. Sales tax mapping resets
Marketplace facilitator rules mean the marketplace collects and remits sales tax on your behalf in most US states, and the accounting treatment of those amounts is specific. They flow through your settlement but they are not your revenue and not your liability.
Tools handle this differently, and a mismapped facilitator tax line is one of the few errors that can make your revenue look materially wrong rather than just misclassified. State requirements vary, and the Federation of Tax Administrators directory of state tax agencies is the reliable route to a given state’s current position. Anything specific to your situation belongs with a tax professional rather than a software setting.
A cutover sequence that works
Run both tools in parallel for one full settlement cycle, with the new one posting to a copy of your ledger or to a set of holding accounts rather than live. Compare the two outputs line by line. Differences at this stage are cheap to investigate and tell you exactly where the mappings diverge.
Then close the old month completely, lock it, take the inventory count, enter opening balances, and start the new tool on a fresh settlement. Keep the old tool’s export files permanently, not just until the migration looks finished.
Choosing what to switch to
The selection criteria are narrower than the marketing suggests. Which channels do you actually sell on, how far back do you need history, does it post cost of goods sold at the tier you will realistically pay for, and does it write to the accounting system you already use.
The market splits roughly into settlement reconciliation specialists such as A2X and Link My Books, and broader platforms that carry inventory and SKU-level profit alongside the sync, a group that includes ConnectBooks. The second category does more, and correspondingly has more to configure during a migration. Neither is the better answer in the abstract. The answer depends on whether your problem is getting the settlement into the ledger correctly, or knowing which products are worth reordering, and those are genuinely different problems.