Best Accounting Software for Amazon Sellers (UK)

Last updated: March 2026

For Amazon sellers in the UK, accounting software is not just a feature choice, it underpins how revenue, VAT, and compliance are handled. Whether you use Xero or QuickBooks, the system should reflect Amazon’s settlement mechanics through appropriate integration tools such as A2X or Link My Books; otherwise revenue, VAT, and margins may be misstated.

This guide outlines the accounting architecture commonly used to support HM Revenue & Customs record-keeping expectations under Making Tax Digital, while remaining scalable as transaction volume increases. By the end, you’ll have a clear view of which software setup fits your VAT position, sales channels, and stage of growth – and which configurations could expose you to unnecessary compliance risk.

Contents

~45–55 min read · Updated February 2026

Use this contents menu to jump directly to the section you need.

• Introduction: Why Amazon Sellers Need Specialist Accounting Software
• What Amazon Sellers Actually Need from Accounting Software
• Xero vs QuickBooks for Amazon Sellers (UK)
• Amazon Integration Tools: A2X vs Link My Books
• Stripe & PayPal Integration for Multi-Channel Sellers
• Inventory & COGS: Where Most Software Falls Short
• Accounting Software Costs for Amazon Sellers: What Actually Drives the Price
• Recommended Software Stacks by Seller Type
• Common Software Mistakes Amazon Sellers Make
• How to Choose the Right Accounting Software (Decision Framework)

1. Introduction: Why Amazon Sellers Need Specialist Accounting Software

Many UK Amazon sellers assume accounting software is broadly interchangeable. If it connects to a bank account, produces a profit and loss report, and allows VAT returns to be filed, it can appear sufficient.

Amazon does not operate like a typical small business.

It does not pay per order. It aggregates sales, refunds, referral fees, fulfilment charges, advertising costs, storage fees, and VAT adjustments into periodic settlements. Those settlements rarely align neatly with calendar months or VAT quarters. Bank deposits represent net outcomes, not underlying transactions.

This creates structural accounting challenges that generic setups are not designed to handle.

If Amazon settlements are recorded only at payout level, revenue can be understated, fees lose visibility, VAT becomes harder to evidence, and reconciliation weaknesses may not become visible until VAT registration, year-end accounts preparation, or a compliance review.

For UK sellers, accounting software is therefore not just a bookkeeping tool. It forms part of the compliance infrastructure that supports:

• VAT reporting under UK rules
• Making Tax Digital record-keeping requirements
• Inventory and cost of goods recognition
• Multi-channel reconciliation (Amazon, Stripe, PayPal, Shopify)
• The ability to explain figures clearly if HMRC requests evidence

Choosing an appropriate system early does not eliminate complexity, but it can reduce structural risk and limit the need for retrospective correction as transaction volumes increase.

For a structured overview of how Amazon settlements, VAT, inventory, and reporting fit together in the UK, see Amazon Seller Accounting – Complete Guide.

Why Amazon breaks standard accounting software setups

Amazon FBA and FBM operations do not follow the direct payment model that most small-business accounting software is designed around.

In a typical business, a customer pays the business directly, fees are incurred separately, and the full sale value passes through the bank account. Amazon reverses this flow. When a customer places an order on Amazon, payment is made to Amazon rather than to the seller. Amazon then deducts referral fees, fulfilment fees, storage charges, advertising costs, refunds, and other adjustments before any funds are paid out to the seller.

In many cases, Amazon also withholds amounts temporarily, for example under rolling reserve arrangements or delivery-delay policies. From an accounting perspective, this creates a clearing-style flow rather than a simple receipt of income.

Generic bookkeeping workflows often assume that money received into the bank represents revenue. For Amazon sellers, the bank deposit is only the net result of a larger set of transactions that have already occurred. A single Amazon payout may reflect hundreds or thousands of individual sales, multiple fee categories, VAT charged or withheld under marketplace rules, and timing differences caused by refunds or delivery delays.

When this activity is compressed into a single line in the accounting system, important information is lost.

Amazon settlement reports illustrate this clearly. A settlement statement breaks activity into gross sales, refunds, promotional discounts, individual fee categories, VAT amounts, reserves held, and prior reserves released. A bank feed, by contrast, shows only a single net deposit.

Without software that can disaggregate settlement data, the accounting records may not accurately reflect what occurred during the period.

Settlement periods also do not align neatly with calendar months. Delivery-based holds and delayed refunds can push cash receipt into later periods even though the underlying sale has already taken place. Where sellers rely solely on payout-based accounting, sales and fees are often reported in the wrong period, which can distort management reporting and complicate VAT calculations.

Under Making Tax Digital and general record-keeping requirements, businesses are required to maintain records that can explain how figures on VAT returns and tax computations have been calculated. Where figures are derived solely from bank deposits, it can be difficult to demonstrate how reported revenue, fees, and VAT reconcile back to Amazon’s own records if queried.

The risk of using generic bookkeeping tools

Using generic bookkeeping software for Amazon sales is not inherently non-compliant, but it can create avoidable compliance risk as a business scales.

One of the most common issues is the misclassification of Amazon payouts as turnover. When net settlements are treated as sales, embedded fees are effectively hidden within the revenue figure. This can make margins appear stronger than they are and remove visibility over one of the largest cost drivers in an Amazon business.

VAT reporting introduces further complexity. Amazon may charge VAT on certain seller fees and, in some scenarios, may collect and account for VAT from customers under online marketplace rules. Generic tools and non-specialist workflows often struggle to separate VAT on fees from the underlying expense or to identify VAT that Amazon has already accounted for.

The result can include missed VAT reclaims, incorrect VAT returns, or inconsistencies between marketplace data and the figures submitted by the seller.

During VAT inspections or compliance checks, HMRC may ask businesses to explain how figures on a VAT return or tax computation were derived and to provide supporting records. If the accounting system only shows net deposits and high-level expense totals, sellers may be forced into retrospective reconstruction using settlement reports and spreadsheets.

This process is time-consuming and costly, and it increases the risk that HMRC views errors as systemic rather than isolated. Sellers who scale on unsuitable systems often need months of historical settlement data to be reprocessed. Correcting past VAT returns, restating accounts, and responding to HMRC enquiries can involve material time and cost compared to maintaining a structured accounting setup from the outset.

What “Amazon-compatible” actually means

Amazon-compatible accounting software is not defined by whether it can import a bank transaction labelled “Amazon”. It is defined by whether the system can reflect Amazon’s settlement mechanics accurately and in a way that meets UK record-keeping expectations.

In practice, Amazon-compatible software works from settlement data rather than payouts. Gross sales, refunds, individual fee categories, VAT components, and reserves are recorded as separate elements rather than collapsed into a single net figure.

Clearing accounts play a central role in this structure. They allow the accounting system to show what Amazon owes the seller, what has been withheld, and what has been paid. This also supports clearer month-end cut-offs and more reliable cash-flow forecasting.

From a VAT perspective, Amazon-compatible systems should be capable of distinguishing between VAT on sales for which the seller is responsible, VAT charged on Amazon fees, and VAT accounted for by Amazon under marketplace rules, where applicable. Without this separation, VAT returns are more likely to contain errors or require manual adjustments.

Equally important is the audit trail. Software that produces settlement-level postings, preserves transaction detail, and maintains digital links between source data and reported figures is easier to support if HMRC asks how a figure was calculated.

How the right software saves tax, time, and penalties

Automating the import and processing of Amazon settlements reduces manual reconciliation work and reliance on spreadsheets. Separating VAT on Amazon fees helps VAT-registered sellers reclaim input tax where supported by valid invoices, while correctly handling marketplace-collected VAT reduces the risk of over- or under-reporting.

Over time, differences between correct and incorrect VAT treatment may become financially material. When fees and other costs are properly categorised, corporation tax or income tax is calculated on a more accurate profit figure rather than on a margin distorted by net reporting.

This may reduce the likelihood of underpayments that later attract interest or penalties, depending on the circumstances. Sellers using settlement-level systems are also better placed to respond efficiently to HMRC queries because supporting documentation and reconciliation evidence are already organised and traceable.

From HMRC’s perspective, the key issue is not the software brand but whether records can be traced clearly from Amazon settlement data through to the figures filed.

In practice, some UK Amazon sellers report that specialist accounting software can cost less over time than manual fixes, retrospective clean-ups, and repeated professional intervention. The benefits are not only financial but operational, allowing sellers to focus on running and growing the business rather than unpicking avoidable accounting problems.

2. What Amazon Sellers Actually Need from Accounting Software

Most accounting software is built around a simple commercial assumption: one customer pays one invoice, money is received into the bank, and that receipt represents revenue. Amazon does not operate that way.

For UK Amazon sellers, accounting software is not merely a bookkeeping tool. It forms part of the compliance infrastructure that supports VAT returns, Making Tax Digital submissions, year-end accounts prepared under UK GAAP, and the ability to explain figures coherently if HMRC raises a query. The requirements are therefore structural rather than cosmetic.

Before comparing specific tools, it is important to define what Amazon sellers actually need from accounting software in practice.

For a detailed walkthrough of how Amazon settlement reports reconcile to clearing accounts and bank receipts, see Amazon Payout Reconciliation – Step-by-Step.

Handling Amazon settlement reports, not just payouts

Amazon settlement reports are generally the primary accounting source for seller activity. Bank payouts represent only the net outcome.

A settlement report breaks each settlement period into its underlying components, including gross sales, refunds, promotional discounts, individual fee categories, VAT amounts, reserves held or released, and other adjustments. A single settlement may contain hundreds or thousands of transactions, each timestamped and categorised.

By contrast, a payout is a single bank deposit that represents the net result of those transactions. It does not explain how the figure was calculated.

From an accounting perspective, relying on payout data alone introduces several risks. Gross revenue may be understated because fees and refunds are embedded in the net figure. VAT reporting becomes harder to support because VAT on fees and any marketplace-collected VAT cannot be identified clearly. Period cut-offs can also be distorted, as settlement periods do not align neatly with calendar months and delivery-based holds can delay cash receipt.

HMRC expects digital records to be sufficient to explain how figures on VAT returns and tax computations are derived. Where figures are produced solely from bank deposits, it can be difficult to demonstrate how reported revenue, fees, and VAT reconcile back to Amazon’s own records during a compliance check.

For this reason, accounting software used by Amazon sellers will often work from settlement-level data rather than payout-level data. This allows each component of the settlement to be recorded separately, supporting both accuracy and auditability.

Clearing account support is generally regarded as a core structural requirement

A clearing account is the mechanism that allows settlement data to reconcile to bank receipts without distorting revenue.

When settlement data is posted correctly, gross sales, fees, refunds, and reserves are recorded first against a clearing account. That clearing account represents the amount Amazon owes the seller at a given point in time. When the payout reaches the bank, it clears that balance.

Without a clearing account, several controls tend to fail. Revenue is often recorded as the net payout rather than the gross sale value. Amounts withheld by Amazon are not visible, leading to cash-flow misunderstandings. Chargebacks and delayed adjustments appear disconnected from the original transactions. Month-end reconciliations frequently fail to balance cleanly.

From an HMRC perspective, weaknesses in clearing account logic are relatively easy to identify. Persistent unexplained balances, inconsistencies between settlement totals and bank receipts, or the absence of a clearing structure altogether are common areas of enquiry.

Any accounting system used by an Amazon seller should support clearing accounts as a core feature, applied consistently and reconciled regularly.

VAT handling for UK and EU sales

VAT is where generic accounting setups most commonly fall short for Amazon sellers. For a detailed breakdown of how Amazon fee VAT, deemed supplier rules, and Box 1/Box 6 treatment interact in practice, see FBA VAT for Amazon Sellers – What You Need to Know.

UK VAT outcomes vary depending on factors such as where goods are located, where the seller is established, and whether online marketplace deemed supplier rules apply. In some scenarios, the seller accounts for output VAT in the normal way. HMRC explains when the marketplace (rather than the seller) may be responsible for VAT in Charging VAT when using an online marketplace.

Seller-accounted output VAT on UK taxable sales feeds into Box 1 of the VAT return. VAT charged on Amazon fees may be recoverable in Box 4 where the seller is VAT-registered and entitled to recover it. Where Amazon is treated as the deemed supplier under online marketplace rules and accounts for VAT on the sale, that VAT is generally not included in the seller’s own output VAT, subject to the specific facts of the transaction. The position should be supported by appropriate evidence within the audit trail. Box 6 would ordinarily reflect the correct value of supplies excluding VAT, rather than net settlement payouts.

EU sales introduce further complexity. Depending on the supply chain, registration status, and marketplace involvement, VAT may be reported through OSS, charged at destination-country rates, or accounted for by Amazon under deemed supplier rules. Accounting software should be capable of distinguishing these flows consistently and retaining evidence to support the treatment adopted.

HMRC has the ability to obtain and review marketplace data when conducting compliance activity. Where VAT figures cannot be reconciled back to settlement reports and VAT statements, enquiries are more likely.

Multi-currency and FX revaluation capability

Even UK-based Amazon sellers frequently have foreign-currency exposure. EU marketplaces settle in euros, and Amazon may convert those amounts to sterling before payout or pay them into a foreign-currency account.

Under UK accounting standards, monetary balances such as Amazon receivables are translated at the transaction date and revalued at the period end if they remain outstanding. Resulting foreign exchange gains or losses are recognised in profit and loss for corporation tax purposes. VAT is based on the sterling value at the relevant tax point, and subsequent exchange movements generally do not alter the VAT due.

If accounting software cannot handle multi-currency balances and automated FX revaluation, several issues can arise. Margins may appear distorted because exchange differences are embedded within net receipts. Unrealised gains or losses may be omitted at month end. VAT figures may become contaminated by currency movements that should not be included.

For Amazon sellers with EU exposure, FX handling is not an advanced feature. It is a practical requirement for reliable reporting.

Inventory and cost of goods sold support

Inventory and cost of goods sold are often the largest figures in an Amazon seller’s accounts, yet they are frequently misreported.

Under UK accounting principles, inventory costs are recognised when goods are sold, not when they are purchased. Posting purchases directly to cost of goods sold at the time of payment can distort profit between periods.

Amazon FBA adds further complexity. Inventory may be held across multiple fulfilment centres. Units can be lost or damaged and reimbursed weeks later. Reimbursements should be linked to inventory movements and cost recovery, rather than treated as sales income or used to reverse COGS incorrectly.

Accounting software should be capable of supporting FIFO or weighted-average costing, landed-cost allocation, and reconciliation to Amazon inventory reports, where those methods are applied. HMRC expects businesses to be able to evidence closing inventory quantities and values using contemporaneous records, commonly Amazon inventory ledger reports supported by supplier documentation.

As inventory complexity increases, third-party inventory tools may be appropriate. Where these are used, the accounting system still needs to receive accurate inventory and COGS figures in a way that can be explained and evidenced.

MTD-compliant digital audit trail

Making Tax Digital has shifted HMRC’s focus from outcomes alone to the processes used to arrive at them.

A compliant system maintains digital links from source data through to VAT submissions. Manual copying, re-keying figures from CSV files, or summarising data outside the accounting system can break the digital audit trail.

For Amazon sellers, this generally means settlement data is imported into the accounting system via automated imports, structured uploads, or API connections, with digital links preserved end to end where required under MTD rules.

Each posting should reference the source settlement, retain transaction dates, and be traceable back to Amazon records. During inspections, HMRC increasingly reviews bookkeeping systems as well as VAT returns. Sellers may be asked to produce settlement reports, reconciliation schedules, and explanations of how figures were calculated.

Accounting software should therefore support document retention, clear referencing, and defensible audit trails as standard.

3. Xero vs QuickBooks for Amazon Sellers (UK)

Choosing between Xero and QuickBooks is an important early decision for many UK Amazon sellers. Both platforms are MTD-compliant, widely used by UK accountants, and can support HMRC-defensible accounts when configured and reviewed appropriately.

The difference is not whether they work, but how well they align with Amazon’s operating model at different stages of growth.

This comparison focuses on ecosystem fit rather than surface features. The right platform depends on transaction volume, VAT complexity, sales channels, and how much structural discipline the business requires.

To see how these controls operate in a practical monthly workflow, see Amazon Seller Bookkeeping Checklist (Free Template).

Overview: Xero and QuickBooks positioning

Xero is designed around clarity, visual workflows, and consistency. Its UK documentation and accountant guidance generally assume a business that values clean reconciliations, clear audit trails, and a standardised month-end process. This aligns well with Amazon sellers who post settlement summaries rather than individual orders and rely on clearing accounts to reconcile payouts.

QuickBooks positions itself around automation, rule-based processing, and flexible reporting. Its guidance assumes higher transaction volumes, multiple sales channels, and a willingness to invest time upfront in configuration to reduce manual work later. This often appeals to sellers who want granular profitability reporting by channel or SKU and are comfortable with a more complex chart of accounts.

In practice, many UK accountants tend to standardise Amazon clients as follows:

• Xero paired with specialist Amazon middleware for settlement-level posting
• QuickBooks used where multi-channel reporting or higher transaction volumes justify the added complexity

Neither approach is inherently more compliant. Risk arises when the platform’s underlying assumptions do not match the seller’s commercial reality.

Amazon integration capability (native vs third-party)

Neither Xero nor QuickBooks provides a native Amazon integration that is suitable for settlement-level accounting on its own.

Amazon does not operate on a simple “one order, one payment” model. A single payout can include sales from multiple delivery dates, refunds, reserves, reimbursements, and VAT handled under different rules. UK accounting and VAT records are expected to reflect those underlying transactions, not just the net cash movement.

For this reason, both platforms typically rely on third-party middleware such as A2X or Link My Books to:

• disaggregate Amazon settlement reports into sales, fees, refunds, and VAT components
• allocate transactions to the correct accounting periods
• preserve a digital audit trail back to Amazon Seller Central

QuickBooks does offer a native Amazon connector, but it operates at individual order level. For many UK sellers, this introduces volume, reconciliation, and audit-trail challenges rather than resolving them. As a result, many accountants avoid order-level imports for Amazon and use settlement-level middleware instead, particularly as transaction volumes increase.

From a compliance perspective, the integration layer is often more significant than the accounting platform itself. Using Xero or QuickBooks without appropriate settlement integration may increase the risk of misstated revenue and VAT, particularly as transaction volumes grow.

VAT and Making Tax Digital handling

Both platforms support Making Tax Digital and direct VAT submissions to HMRC, but their VAT workflows differ in emphasis.

Xero’s VAT reporting is ledger-driven. Each transaction carries a VAT code, and VAT returns are generated directly from the general ledger. This can make it easier to review Box 1, Box 4, and Box 6 figures against underlying postings, provided settlement data has been imported and coded correctly.

QuickBooks places greater emphasis on prompts and exception-style reporting within the VAT workflow. It highlights unusual movements and allows pre-submission review and adjustments, which can help identify inconsistent VAT treatment in more complex scenarios. In practice, VAT accuracy still depends primarily on correct settlement mapping and review rather than on the platform alone.

In both systems, VAT outcomes for Amazon sellers depend less on the VAT module itself and more on whether:

• Amazon-collected VAT is excluded correctly
• VAT on Amazon fees is reclaimed where the seller is VAT-registered and entitled to recover it, supported by valid VAT invoices
• settlement periods are split accurately across VAT quarters

Middleware performs much of this logic. Without it, both platforms are exposed to similar HMRC risks.

Inventory tracking limitations

Native inventory features are a weak point in both Xero and QuickBooks for Amazon sellers.

Neither platform reflects Amazon FBA operations particularly well. Inventory may be held across multiple fulfilment centres, lost or damaged, reimbursed weeks later, or returned in varying condition. Operational inventory data sits primarily in Amazon’s inventory reports, not in the accounting system.

In Xero, native inventory is capped and limited in functionality. In QuickBooks, inventory is more flexible but highly dependent on correct item setup and ongoing cost maintenance.

In both cases, relying solely on native inventory tools can lead to incorrect COGS, mismatched balance sheets, and confusing reimbursement treatment if not carefully managed.

As a result, many UK accountants:

• limit or disable native inventory tracking as sellers scale
• rely on Amazon inventory reports for quantity evidence
• post periodic inventory and COGS adjustments to the general ledger

Where inventory becomes business-critical, third-party inventory systems are often layered on top, with Xero or QuickBooks acting as the financial ledger rather than the operational source of truth.

Reporting quality and review discipline

Xero’s default reports are clean and accessible, but they can obscure how much Amazon retains in fees unless the chart of accounts is structured carefully. Without settlement-level disaggregation, sellers may focus on headline revenue rather than net contribution.

QuickBooks makes it easier to separate revenue and fees by channel and category, which can improve profitability analysis for multi-channel sellers. The trade-off is complexity. Poor configuration can produce highly detailed reports that are still unreliable.

In both systems, accountants extract audit-ready figures by:

• reconciling clearing or receivable balances to Amazon settlements
• retaining settlement reports as source evidence
• ensuring reported revenue and VAT can be traced back to Amazon data

The platform does not remove the need for review. It simply changes where risk tends to arise.

Which platform suits which seller

Xero is often well-suited to:

• UK-only sellers in early or steady growth stages
• sellers with EU or multi-currency exposure
• businesses working closely with UK accountants who standardise on Xero
• sellers who want a clean, repeatable month-end process

QuickBooks often becomes attractive when:

• the business is genuinely multi-channel and needs channel-level profitability reporting
• transaction volumes justify deeper automation
• the seller is comfortable with a more complex setup to gain reporting flexibility

The key point is this: both platforms can support compliant accounting outcomes, but neither is forgiving when misaligned with the underlying business model. Choosing a platform that is misaligned with the underlying business model can result in restructures or migrations later, which may involve additional cost and disruption.

4. Amazon Integration Tools: A2X vs Link My Books

Selling through Amazon creates a transaction volume and data structure that does not behave like a conventional online shop or a traditional invoicing business. Amazon does not issue individual sales invoices to sellers. Instead, it aggregates activity into settlement statements that combine sales, refunds, fees, VAT movements, and timing adjustments across multiple days or weeks.

For UK e-commerce businesses, this can make direct posting of Amazon data into accounting software increasingly difficult as transaction volumes grow. While it may be possible to manage low volumes manually using spreadsheets or basic journals, this approach commonly breaks down as order counts, VAT complexity, and reconciliation demands increase.

In practice, once Amazon becomes a material sales channel, many businesses adopt integration tools to help maintain accurate bookkeeping, reliable VAT reporting, and audit-ready records under UK accounting standards and HMRC record-keeping requirements.

Why Posting Amazon Payouts Manually Becomes Increasingly Difficult at Scale

Amazon does not pay sellers per order. Instead, it issues settlement statements, typically every 14 days, which aggregate hundreds or thousands of underlying transactions into a single payout.

A single settlement can include:

• Gross sales across multiple VAT rates
• Customer refunds processed days or weeks after the original sale
• Amazon referral, fulfilment, storage, and advertising fees
• VAT collected by Amazon under marketplace facilitator rules
• VAT charged by Amazon on its fees
• Chargebacks, reimbursements, and reserve adjustments
• Timing differences between delivery dates and payout dates

Manually posting a single net payout figure into software such as Xero or QuickBooks ignores this structure. While the bank balance may reconcile, the profit and loss account and VAT return will not reflect the underlying activity.

For example, an illustrative UK Amazon FBA settlement for a seller with £150,000 annual turnover might include:

• £12,000 of gross sales split across standard-rated and zero-rated products
• £2,800 of Amazon fees
• VAT on those fees, which may be charged by Amazon UK depending on contractual and establishment arrangements, and may be recoverable as input VAT where the seller is entitled to recover it
• Marketplace facilitator VAT collected by Amazon on qualifying UK or EU sales
• Refunds linked to prior settlement periods

Posting only the £9,200 net payout removes this detail. From an HMRC perspective, this can create evidential and reconciliation challenges in relation to:

• VAT evidence and traceability
• Digital record-keeping under Making Tax Digital
• Explaining how Box 1 and Box 6 figures were derived

HMRC’s record-keeping requirements are set out in VAT Notice 700/21 (Keeping VAT records and accounts), which explains the expectation to retain VAT records (and, where relevant, digital links) that support how VAT figures are calculated. At low volumes, some sellers manage with spreadsheets. As transaction volumes increase, this may increase the risk of VAT errors, misstated margins, and more complex HMRC enquiries.

How A2X Works (Settlement-First Logic)

A2X is built around a settlement-first accounting model. Rather than prioritising VAT outputs, it treats each Amazon settlement as the primary accounting event and reconstructs the underlying activity in the general ledger.

In practice, A2X connects directly to Amazon Seller Central and imports settlement reports. Each settlement is broken down into sales, refunds, fees, and taxes, which are then posted into the accounting system using predefined mappings.

A typical A2X posting flow for a UK seller is:

1. Amazon issues a settlement statement
2. A2X imports and parses the settlement
3. Sales are posted to revenue accounts, often split by VAT rate or jurisdiction
4. Amazon fees are posted to expense accounts
5. VAT on fees is posted to an input VAT account where applicable
6. The net settlement is posted to an Amazon clearing account
7. The bank payout clears that balance

This approach produces a detailed audit trail from settlement to ledger to bank. For accountants preparing statutory accounts under UK GAAP, this level of detail supports accrual accounting, margin analysis, and reconciliation.

When configured appropriately, A2X can allocate revenue based on delivery data rather than payout timing. This is relevant where delivery dates and settlement dates fall into different accounting periods.

The trade-off is complexity. Initial setup requires careful mapping, and ledger volumes can be high. This is generally acceptable where sellers work with accountants or finance teams, but may feel heavy for DIY users.

How Link My Books Works (VAT-First Logic)

Link My Books takes a VAT-first approach designed around UK VAT compliance for Amazon sellers. Rather than reconstructing every settlement line in the general ledger, it focuses on producing VAT-accurate, reconciliation-ready summaries by design.

Link My Books connects to Amazon and aggregates settlement data into structured postings aligned directly with VAT return logic. Sales are grouped by VAT treatment, and fees and associated VAT are handled in line with current UK rules.

In practice:

• Amazon sales are classified by VAT responsibility
• Product groups handle mixed VAT rates
• Settlements are converted into summary journals or invoices that reconcile to the bank payout
• Clearing accounts typically return to zero each period, simplifying month-end close

For sellers newly registered at the £90,000 VAT threshold, this structure materially reduces risk. Box 1 and Box 6 figures are generated from structured data rather than manual calculations, helping to prevent common early-stage VAT errors.

The VAT-first model produces fewer ledger entries and is easier for non-accountants to review. The trade-off is that settlement-level forensic detail sits primarily within the Link My Books interface rather than directly in the general ledger. For most HMRC enquiries, VAT accuracy and reconciliation evidence are more relevant than line-by-line postings.

Handling Facilitator VAT and OSS Logic

Marketplace facilitator VAT is a frequent failure point. In many UK and EU scenarios, Amazon is treated as the deemed supplier and collects and remits VAT on the sale.

Where Amazon is treated as the deemed supplier under online marketplace rules, the seller generally reports the net sale value but does not include VAT collected by Amazon in their own output VAT.

Both A2X and Link My Books are designed to support this, using different mechanisms:

• A2X typically posts facilitator VAT to balance sheet accounts, excluding it from the VAT return
• Link My Books classifies these sales into marketplace-responsible VAT groups so the VAT does not enter Box 1 where marketplace deemed supplier rules apply

For sellers using the EU One Stop Shop scheme, both tools separate UK VAT from EU VAT data. From an HMRC defensibility perspective, an important requirement is the ability to evidence:

• Which sales were subject to marketplace rules
• Why VAT was or was not included in Box 1
• How reported figures reconcile to Amazon VAT reports

Reconciliation Accuracy and Audit Trail

A2X provides settlement-level audit trails, with each settlement traceable through the ledger and into the bank via clearing balances. This is valuable where accrual accuracy or forensic detail is required.

Link My Books prioritises payout-level reconciliation. Settlement summaries are designed to match bank deposits exactly, allowing clearing accounts to zero out cleanly and speeding up month-end close.

In both cases, sellers are required to retain sufficient records, which typically include Amazon settlement reports, VAT transaction reports, and bank statements. Integration tools automate processing, but they do not remove the obligation to keep underlying records under VAT Notice 700/21, including reconciliation schedules.

Which Tool Fits Which Seller Profile

A2X typically suits:

• High-volume FBA sellers
• Sellers operating across multiple EU marketplaces
• Businesses working with accountants who want settlement-level audit trails
• Sellers requiring accrual accounting by delivery date

Link My Books typically suits:

• UK-only sellers registered for VAT
• Sellers with mixed VAT-rate products
• Multi-channel businesses selling via Amazon, Shopify, or eBay
• Owner-managed businesses prioritising fast month-end close

For many UK Amazon sellers, the deciding factor is workflow rather than features. Accountants often have strong preferences based on how they manage reconciliation, VAT review, and reporting across multiple clients.

Once Amazon becomes a material sales channel, many businesses implement structured integration in practice. It forms the foundation of accurate UK e-commerce accounting, compliant VAT reporting, and defensible records if HMRC asks how the numbers were produced.

5. Stripe & PayPal Integration for Multi-Channel Sellers

Selling on Amazon alongside a direct-to-consumer channel introduces a structural accounting challenge that many UK e-commerce businesses underestimate. Amazon operates on a settlement-based model, while payment processors such as Stripe and PayPal operate on transaction-based models. When these systems are not brought together within a single accounting framework, accounting records may reflect only part of the business activity.

Amazon aggregates activity into settlement statements and pays sellers a net amount after fees, refunds, and adjustments. Stripe and PayPal, by contrast, record each customer transaction individually, deduct fees at transaction level, and pay out funds on a rolling basis. These differences create complexity around revenue recognition, VAT treatment, reconciliation, and the construction of a defensible audit trail.

This section explains why Stripe and PayPal complicate Amazon-led bookkeeping, how net versus gross treatment can distort turnover and VAT reporting, why fee VAT treatment differs by provider, and why clearing accounts are commonly required for accurate multi-channel accounting.

For a detailed explanation of reverse charge treatment and VAT reporting for Stripe fees, see How Stripe Fees Are Treated in Accounting.

Why Stripe and PayPal Complicate Amazon Bookkeeping

Amazon does not pay sellers per order. Instead, it aggregates sales, refunds, fees, and adjustments into settlement statements, typically issued every 14 days. Each settlement results in a single net payout to the seller’s bank account.

Stripe and PayPal operate differently. Each customer payment is recorded individually at gross value. Processing fees are deducted per transaction, and payouts are made daily or every few days depending on account settings, risk profile, and reserve arrangements.

This creates several structural differences:

• A significantly higher volume of accounting entries
• Different timing between sale, fee deduction, and bank receipt
• Separate fee, dispute, and chargeback flows
• Funds held temporarily outside the main bank account

Problems arise when sellers attempt to treat Stripe or PayPal payouts in the same way as Amazon settlements. A common error is posting only the net bank deposit from Stripe or PayPal as revenue, while Amazon sales are recorded using a settlement-based integration. Mixing these approaches breaks reconciliation logic and obscures the true performance of the business.

In practice, accountants may identify this issue during bank and revenue reviews. A business may show £110,000 of bank deposits over a period, while the profit and loss account reflects only £105,000 of revenue. The difference may arise where Stripe or PayPal fees have not been recorded separately, or where timing and reconciliation differences exist.

From a compliance perspective, risk increases where multi-channel revenue is not consolidated. HMRC’s Selling goods or services on a digital platform (HMRC reporting rules for sellers) explains how platforms may collect and report seller and income information under OECD-aligned rules. Where Amazon sales appear in the accounts but Stripe or PayPal activity does not, discrepancies between platform-reported data and declared figures may increase the likelihood of follow-up questions during compliance activity.

Net vs Gross Revenue Handling

Stripe and PayPal both report transactions gross of fees. If a customer pays £100 through Stripe, Stripe records a £100 charge. A processing fee is deducted, typically around £3.20, leaving £96.80 to be paid out. PayPal operates on the same principle, recording the full transaction value and deducting its fee separately.

Amazon, by contrast, pays sellers net of fees. This difference leads some sellers to apply net-posting logic incorrectly to Stripe and PayPal.

Posting net receipts as revenue can create several issues:

• Turnover is understated
• Gross margins are distorted
• Processing fees are hidden within revenue
• VAT threshold monitoring becomes unreliable

The UK VAT registration threshold test is based on taxable turnover over a rolling 12-month period (not net cash received) – see Register for VAT. For a breakdown of how the rolling test operates in practice, see UK VAT Thresholds Explained. A seller processing £92,000 of Stripe payments may see only £89,000 reach the bank after fees and incorrectly assume they remain below the threshold. Platform-reported data, however, can reflect the full gross transaction value.

From an accounting perspective, a common treatment is to record gross sales as revenue, record Stripe or PayPal fees as separate expenses, and use clearing accounts to manage timing differences between transactions and bank payouts.

Fee VAT Treatment Differences

Although Stripe, PayPal, and Amazon fees may appear similar, their VAT treatment differs.

PayPal fees are generally VAT exempt because PayPal is treated as supplying exempt financial services. No VAT is charged on PayPal fees, and there is typically no VAT to reclaim.

Stripe fees are treated differently. Stripe provides payment facilitation services rather than exempt financial services and is commonly an overseas supplier to UK merchants. As a result, the reverse charge may apply depending on the supplier entity, place of supply rules, and the seller’s VAT status. Stripe may not charge VAT on its invoices, and where the reverse charge applies, the UK business is required to self-account for VAT at the applicable rate and report it as both output and input VAT, subject to its entitlement to recover input VAT.

Amazon’s treatment of seller fees changed from August 2024. For UK-based sellers, Amazon may charge UK VAT at the standard rate on seller fees, depending on the contractual entity and place of supply. This VAT is reclaimable by VAT-registered businesses that are not using the Flat Rate Scheme and are entitled to input tax recovery.

In practice, this means that three superficially similar costs can receive three different VAT treatments:

• PayPal fees are generally VAT exempt
• Stripe fees commonly fall under the reverse charge
• Amazon fees are usually standard-rated with UK VAT

Incorrect VAT coding can distort VAT returns and increase compliance risk, particularly where PayPal fees are treated as reverse-charged or Stripe fees are recorded as exempt without review.

Clearing Accounts vs Direct Bank Feeds

Stripe and PayPal commonly require clearing accounts rather than direct-to-bank posting once transaction volume becomes meaningful. The underlying reason is timing. Stripe may take several days to pay out, while PayPal may hold funds for longer due to compliance checks, disputes, or rolling reserves.

A clearing account represents this interim position. Sales and fees are posted to the clearing account when they occur. When the payout reaches the bank, the clearing account balance is cleared.

Without clearing accounts:

• Sales recorded before payout can create unexplained reconciliation differences
• Fees are often omitted or misclassified
• Chargebacks appear as unexplained bank movements
• Period-end reconciliation becomes unreliable

Amazon already operates on a settlement and clearing-style model. Extending that logic to Stripe and PayPal creates consistency across all channels.

A structured multi-channel setup commonly includes:

• An Amazon settlement clearing account
• A Stripe clearing account
• A PayPal clearing account
• Separate expense accounts for processing fees

These clearing accounts are typically reconciled regularly to platform reports such as Stripe’s Balance Summary and PayPal’s settlement reports, with differences explained and documented.

For sellers operating at scale, clearing accounts are commonly used as a practical way to maintain compliant, auditable records across Amazon and direct-to-consumer channels.

6. Inventory & COGS: Where Most Software Falls Short

Inventory and cost of goods sold are areas where many UK Amazon sellers assume their accounting software is doing more than it actually is. Xero and QuickBooks both offer native inventory features, but these tools were designed for conventional retail models, not for the settlement-based, exception-heavy reality of Amazon FBA.

For HMRC purposes, inventory figures are expected to be supportable, applied consistently, and capable of being reconciled to evidence. In practice, that evidence usually comes primarily from Amazon’s inventory ledger and settlement reports, supported by supplier invoices and internal records, rather than from the accounting system alone. Where sellers rely on software outputs without reconciling them back to Amazon data, discrepancies can accumulate quietly until they surface at year-end or during an HMRC enquiry.

For a detailed explanation of how inventory valuation, COGS recognition, and Amazon inventory reports interact, see Inventory & Cost of Goods Accounting for Amazon.

Native inventory limits in Xero and QuickBooks

Xero and QuickBooks assume a relatively simple inventory flow. Goods are purchased, held, sold, and expensed as cost of goods sold at the point of sale. That logic works well for businesses shipping directly from their own warehouse. It does not map cleanly onto Amazon FBA.

In an FBA model, inventory movements extend well beyond sales. Units can be lost, damaged, returned, reimbursed weeks later, or held in reserve by Amazon. These events are reflected in Amazon’s inventory ledger and settlement reports, but they are not automatically pushed into Xero or QuickBooks through native functionality.

As a result, several gaps commonly arise:

• Lost or damaged inventory is not written out automatically.
• Reimbursements are paid in cash but are not linked back to inventory or cost of goods sold.
• Refunds often reverse revenue but do not reverse cost of goods sold without manual intervention.
• Reserve holds and settlement timing differences are not visible in the general ledger.

The accounting system may therefore show an inventory balance that cannot be reconciled to Amazon’s own records without additional work. At low volumes this can be manageable. As SKU counts increase and monthly turnover grows, the approach often becomes unreliable and increasingly time-consuming to maintain.

When third-party inventory tools are required

Not every Amazon seller needs specialist inventory software. The trigger is not theoretical complexity, but operational friction.

Third-party tools, or a disciplined settlement-based adjustment process, usually become appropriate when one or more of the following conditions appear consistently:

• Monthly inventory reconciliation takes several hours rather than minutes.
• Lost or damaged inventory adjustments are identified weeks after the event.
• Refund volumes are high enough that manual cost reversals become error-prone.
• Inventory balances increase while sales remain flat, without a clear explanation.
• Year-end inventory adjustments are materially large relative to monthly profit.

For a UK FBA seller with around £150,000 in annual turnover and 30 or more SKUs, these signals often appear together. At that point, sellers typically adopt one of two compliant approaches. Some use third-party tools that summarise Amazon settlement and inventory data into accounting-ready entries. Others retain Xero or QuickBooks as the financial ledger and apply structured monthly journals based on Amazon reports. Both approaches can be acceptable, provided they are applied consistently and documented clearly.

How FBA reimbursements distort COGS

Amazon FBA reimbursements are one of the most common sources of misstatement in Amazon seller accounts. Reimbursements represent compensation for inventory that Amazon has lost or damaged. They are not sales.

When reimbursements are recorded as revenue or miscellaneous income, they inflate turnover and obscure true margins. The underlying issue is that a reimbursement represents a recovery of a cost already recognised elsewhere, rather than new economic activity.

Under generally accepted UK accounting principles, reimbursements are usually treated as a recovery of cost and recorded as a reduction to cost of goods sold rather than as sales income. This distinction matters because reimbursement timing rarely aligns with the original loss. A unit may be lost in January but reimbursed in March. If the reimbursement is treated as income in March, profits appear artificially strong in that month and understated in the period when the loss actually occurred.

From an HMRC perspective, the risk is not only profit distortion but credibility. Where inventory balances, cost of goods sold, and reimbursements cannot be explained by reference to Amazon reports and supporting records, this may prompt further questions during compliance activity.

Reconciling inventory without overengineering

HMRC does not require perpetual, real-time inventory systems for most small and mid-sized businesses. What is generally required is a method that is reasonable, applied consistently, and supported by evidence.

For many UK Amazon sellers, a proportionate approach is sufficient:

• Monthly reconciliation of Amazon settlement reports to bank deposits.
• Regular review of Amazon’s inventory ledger to identify losses, returns, and removals.
• Periodic cost of goods sold adjustments for unreimbursed losses and refunds.
• Documented explanations for timing differences and variances.

A balance sheet figure that can be explained is more defensible than a highly detailed number that no one understands. From an enquiry perspective, HMRC is primarily concerned with whether the method is applied consistently year-to-year and whether movements can be explained using contemporaneous records.

This section sets the foundation for reliable reporting as order volumes increase and operational complexity grows. If financial figures do not explain the business clearly, they may not be fulfilling their intended purpose.

7. Accounting Software Costs for Amazon Sellers: What Actually Drives the Price

When UK Amazon sellers compare accounting software, the decision often starts with the monthly subscription price. That is understandable, but it is also where many cost assumptions begin to diverge from reality.

Xero and QuickBooks are not priced for Amazon businesses in isolation. The headline fee reflects access to a general accounting platform. The total cost only becomes clear once VAT registration, Amazon settlement complexity, integration tools, and the level of professional oversight required are taken into account.

Understanding the total cost of ownership is therefore more informative than comparing advertised monthly prices alone.

Base subscription costs

At face value, Xero and QuickBooks appear similarly priced in the UK market. Entry plans typically sit in the low-to-mid teens per month, while higher tiers commonly range from the mid-thirties to £50 or more.

In practice, many Amazon sellers outgrow entry-level plans relatively quickly. Lower tiers often lack features that become important as Amazon sales increase, such as:

• VAT reporting and Making Tax Digital submissions
• Sufficient transaction limits
• Multi-currency functionality
• Inventory or cost tracking suitable for ecommerce

Sellers frequently encounter these limitations within the first year of trading. As a result, the effective baseline for many Amazon businesses is a mid-tier plan rather than the cheapest advertised option.

Integration costs

Accounting software alone does not handle Amazon settlements reliably at scale. Integration tools are commonly used to translate Amazon’s settlement data into accounting entries that support reconciliation and VAT reporting.

These tools introduce a second cost layer that is often underestimated.

Some integrations price by order volume, while others price by marketplace or sales channel. A seller operating solely on Amazon UK may see modest integration costs, whereas a seller active across multiple EU marketplaces may incur higher fees if each marketplace is treated as a separate channel.

From a total cost perspective, integration fees can approach or exceed the base accounting subscription as order volumes increase. This is not a flaw in the tools themselves. It reflects the complexity of processing high-volume, VAT-sensitive settlement data accurately and maintaining a defensible audit trail.

Hidden costs: fixes and professional time

For many Amazon sellers, the most significant cost is not software. It is correction work.

Poor initial setup or reliance on manual workarounds can lead to issues such as:

• Net Amazon payouts recorded as turnover
• Incorrect VAT treatment on Amazon or payment processor fees
• Unreconciled settlement balances
• Inventory and reimbursement misstatements

These issues rarely surface immediately. They are more commonly identified during VAT registration, year-end accounts preparation, or an HMRC compliance check.

Correcting historical errors is time-intensive and usually billed at professional rates. Over time, reactive clean-up work can represent a material cost and, in some cases, exceed the annual cost of a properly configured software stack.

Cost profile by seller size

For early-stage sellers below the VAT threshold, total software costs are often contained. A basic accounting platform combined with an entry-level integration may be proportionate while transaction volumes remain low.

As turnover approaches the VAT registration threshold, costs typically increase. VAT registration introduces higher evidential standards and more complex reporting requirements. At this stage, sellers often require:

• A higher accounting software tier
• A more capable integration plan
• Periodic accountant involvement for review and reconciliation

As sellers scale beyond approximately £150,000 of annual turnover, professional support may become a more significant cost than the software itself. Software remains essential, but it is no longer the primary driver of total accounting spend.

Software cost versus the cost of mistakes

A single VAT correction, HMRC enquiry, or year-end reconstruction may involve costs that are material relative to the annual cost of a well-configured accounting system.

For most UK Amazon sellers, the relevant question is not whether better software costs more in absolute terms. It is whether the business can absorb the financial and operational cost of errors that arise when systems are underpowered, misaligned, or poorly implemented.

Accounting software should reduce uncertainty and support clear explanations of the numbers. When figures cannot be reconciled or evidenced without significant additional work, the system is no longer serving its purpose.

8. Recommended Software Stacks by Seller Type

Amazon sellers often ask which accounting software is “best”. In practice, the appropriate software stack depends less on brand preference and more on where the business sits operationally and fiscally. VAT status, sales channels, currency exposure, and whether an accountant is involved all materially affect what is required for compliant and efficient bookkeeping.

This section sets out practical, defensible software stacks by seller type, reflecting how UK e-commerce accountants commonly assess Amazon businesses in practice.

UK-only FBA sellers under the VAT threshold

For UK-only Amazon FBA sellers who are not VAT registered, the objective is not sophistication. It is to establish clean foundations that will scale without needing to be rebuilt later.

At this stage, HMRC evidential expectations are proportionate to business size. However, limited companies are still required to maintain proper accounting records on an accruals basis and to be able to explain how reported figures were derived if queried.

A proportionate software stack at this level typically includes:

• Cloud accounting software with UK compliance built in (for example, Xero, QuickBooks, or FreeAgent)
• Active bank feeds for the business bank account
• Manual handling of Amazon settlement reports, provided transaction volumes are genuinely low
• Simple but consistent categorisation of Amazon fees and expenses

What matters most is how Amazon settlements are treated, even before VAT registration. Amazon does not pay sellers per order. It pays via periodic settlements that net together sales, refunds, and fees. Recording only the net payout as “sales” does not reflect the underlying transactions and commonly leads to reconciliation difficulties later.

At low volumes, it is generally acceptable to:

• Download settlement reports monthly
• Record gross sales and total Amazon fees per settlement
• Reconcile each settlement to the corresponding bank deposit
• Retain settlement reports as supporting evidence

What is not appropriate, even at this stage, is:

• Using spreadsheets as the primary accounting system
• Treating Amazon payouts as turnover
• Ignoring VAT charged by Amazon on its own fees, which should be recorded as part of the expense even where it is not recoverable, subject to the seller’s VAT position and the applicable fee structure

As turnover approaches the £90,000 VAT registration threshold on a rolling 12-month basis, sellers are generally expected to monitor their exposure in advance of reaching the threshold. In practice, some accountants suggest closer tracking from around £60,000–£75,000 to allow time for system changes and VAT registration planning where required. For a detailed explanation of when registration becomes mandatory and how the effective date is determined, see VAT Registration for Amazon Sellers – Do You Need It?.

VAT-registered UK sellers

Once a UK Amazon seller becomes VAT registered, software requirements change materially. The focus moves from basic bookkeeping to MTD-compliant, settlement-accurate VAT reporting.

At a minimum, a VAT-registered Amazon seller typically requires:

• MTD-compatible accounting software capable of submitting VAT returns digitally
• An Amazon integration tool such as A2X or Link My Books
• Bank feeds used primarily for reconciliation rather than as a source of sales data

At this stage, many businesses adopt settlement-level integration in practice. VAT returns depend on transaction-level coding, and Amazon settlements commonly include standard-rated sales, zero-rated sales, marketplace-facilitator transactions, VAT on Amazon fees, and, in some cases, reverse-charge services.

Posting net bank deposits without settlement disaggregation may increase the risk of mis-stated Boxes 1, 4, and 6 on the VAT return.

A properly configured stack supports:

• Gross sales feeding correctly into Box 6
• Output VAT appearing only where the seller is liable
• VAT on Amazon fees being reclaimed in Box 4 where permitted
• Reverse-charge services being disclosed correctly

From a risk perspective, this is also the stage at which HMRC data-matching becomes more relevant. Marketplace reporting frameworks mean Amazon’s figures may be available to HMRC during compliance activity, which can make unexplained differences more visible.

Multi-channel Amazon + Shopify sellers

Adding Shopify fundamentally changes the accounting architecture. The business now operates across a marketplace model (Amazon), a direct-to-consumer model (Shopify), and one or more payment gateways such as Stripe or PayPal.

The key structural requirement for multi-channel sellers is the use of separate clearing accounts, typically including:

• An Amazon clearing account for settlements
• A Stripe or Shopify Payments clearing account for card transactions
• A PayPal clearing account where applicable

Sales are typically recorded gross and consistently across all channels, before fees, with refunds and discounts treated symmetrically. Treating Amazon as “net” and Shopify as “gross” within the same ledger can lead to reconciliation issues and distorted turnover and VAT reporting.

In practice, this usually involves:

• Using an Amazon connector and a Shopify connector rather than native order feeds
• Disabling duplicate sales postings from payment gateways
• Reconciling each clearing account independently to platform reports and payouts

From a VAT standpoint, mixed channels introduce additional complexity. Amazon may be the deemed supplier for certain transactions, Shopify sales remain the seller’s own VAT responsibility, and EU distance-selling thresholds apply across all channels in aggregate.

EU / multi-currency Amazon sellers

Selling across EU marketplaces introduces two further layers of complexity: foreign-currency accounting and multi-jurisdiction VAT.

At this level, entry-tier accounting software often proves insufficient as complexity increases. Sellers typically require:

• A multi-currency general ledger with GBP as the functional currency
• EU-aware Amazon integrations capable of splitting sales by country and VAT treatment
• Clear separation between UK VAT, EU OSS sales, and marketplace-deemed-supplier transactions

Foreign-currency settlements are typically translated into sterling for UK VAT and accounting purposes, with exchange differences recognised separately from underlying trading performance in accordance with applicable accounting standards. Without this separation, reported profits can fluctuate for reasons unrelated to underlying sales activity.

Xero and QuickBooks do not natively interpret Amazon’s EU VAT logic without structured configuration or integration tools. Integration tools provide the structure needed to exclude marketplace-handled VAT from UK returns, track EU sales for OSS or local filings, and maintain a defensible audit trail across currencies.

Sellers working with accountants vs DIY

The distinction between DIY and accountant-supported sellers is less about the software itself and more about how tightly it is configured and controlled.

DIY sellers often operate with a single accounting platform, one integration tool, and minimal account structure. This can be appropriate where the seller understands Amazon settlements, VAT coding, and reconciliation discipline.

Accountant-supported setups typically use the same core tools, but on higher tiers, with custom charts of accounts, locked VAT periods, and automation layers designed to reduce manual intervention.

Early software choices matter. Sellers who begin on accountant-friendly platforms can usually move from DIY to supported accounting without rebuilding historical data. Those who delay structural setup or oversimplify early systems may face more extensive clean-up work when VAT registration, EU expansion, or HMRC enquiries require change.

9. Common Software Mistakes Amazon Sellers Make

As Amazon sellers scale, accounting problems rarely arise from bad intentions. They more often arise from software being used in ways it was not designed to handle, until VAT returns, year-end accounts, or HMRC queries bring those weaknesses to light.

Most issues are structural rather than numerical. The figures may look plausible at a headline level, but they cannot be reconciled or evidenced clearly when scrutiny increases. This section outlines the most common software-driven mistakes seen in UK Amazon businesses, and explains why they matter from a compliance and defensibility perspective.

Using Bank Feeds Without Clearing Accounts

One of the most common structural errors is relying on bank feeds alone and posting Amazon payouts directly as income, without using a clearing account.

Amazon does not pay sellers per order. It pays via settlement statements that net together sales, refunds, Amazon fees, advertising charges, storage costs, and other adjustments over a period. When the resulting deposit appears in the bank feed, it represents the net outcome of those transactions, not the underlying revenue.

When sellers post that deposit directly from the bank feed as revenue:

• Revenue is recorded on a cash basis rather than when sales occurred.
• Amazon fees are absorbed into turnover and lose visibility.
• VAT reporting becomes harder to evidence.
• There is no clear control to confirm all settlements have been captured.
• Month-to-month performance comparisons become unreliable.

A clearing account exists to address this. Settlement data is posted to an Amazon clearing account first, broken down into gross sales, refunds, and fees. When the bank payout arrives, it is reconciled against that clearing balance. Where the clearing account does not reconcile, it provides an immediate indicator that something is missing or mis-posted.

In HMRC enquiries, officers may focus on how platform sales reconcile to bank receipts and VAT returns. Where sellers cannot demonstrate this linkage clearly, HMRC may, depending on the facts, question the reliability of the records and seek further explanation or adjustment where appropriate.

Treating Net Payouts as Revenue

Closely related to clearing account issues is treating Amazon’s net payout as turnover.

Under UK accounting principles, revenue should be recorded gross. Amazon’s referral fees, fulfilment charges, storage fees, and advertising costs are operating expenses, not reductions in turnover. Recording only the net payout understates revenue and removes important cost information from the accounts.

This commonly leads to:

• Box 6 on the VAT return potentially being understated.
• VAT threshold monitoring becoming unreliable.
• Gross margins appearing stronger than they are in reality.
• Product-level profitability becoming difficult to assess.
• Differences emerging between Amazon-reported gross receipts and declared turnover.

Amazon settlement reports are designed to show this disaggregation clearly, and accounting integrations exist specifically to preserve it. Ignoring that structure is not merely a shortcut. It weakens the ability to explain how reported figures were derived.

From an HMRC perspective, unexplained differences between marketplace data and declared turnover may prompt further questions about record quality rather than being viewed as isolated calculation errors.

Ignoring VAT Mapping on Fees

VAT mapping errors on Amazon fees have become more common since Amazon’s invoicing changes in August 2024.

Most UK-facing Amazon seller fees are now invoiced with UK VAT. Where accounting software remains configured on pre-August reverse-charge settings, valid input VAT may not be reclaimed through Box 4. This typically results in ongoing cash-flow leakage rather than a single isolated error.

Common indicators include:

• Amazon fee expenses consistently showing no VAT.
• Box 4 appearing low relative to known fee spend.
• VAT invoices available in Amazon’s Tax Document Library that are not reflected in the accounting records.
• Fee VAT treatment remaining unchanged across the August 2024 changeover.

Under Making Tax Digital, VAT returns are expected to be supported by digital records and source documentation. Incorrect VAT mapping breaks the audit trail between Amazon invoices, accounting entries, and VAT return figures. Over time, this increases both financial cost and the likelihood of HMRC queries.

Over-Relying on Inventory Features

Xero and QuickBooks both include inventory features, but these are not designed around the operational reality of Amazon FBA.

In an FBA model, inventory is controlled by Amazon. Stock can be lost, damaged, reimbursed, returned without inspection, or adjusted by Amazon outside the seller’s direct control. Accounting software cannot independently validate these events.

As a result:

• Inventory balances in the software often diverge from Seller Central.
• Cost of goods sold can be misstated.
• Profit fluctuates due to timing differences rather than trading performance.
• Year-end inventory figures cannot be supported without external reports.

HMRC does not require inventory figures to come from accounting software alone. What it expects is that closing inventory values can be supported by independent records. For Amazon sellers, this typically means Seller Central reports, inventory ledger data, and reconciliation schedules that explain differences. Software inventory tools can assist, but they are not a substitute for evidence.

Delaying Automation Too Long

Manual bookkeeping can be appropriate at very low volumes. However, Amazon transaction counts tend to increase quickly, particularly once VAT registration applies.

As volume grows, manual posting becomes increasingly error-prone. Delaying automation often leads to:

• Higher retrospective clean-up costs.
• Multiple VAT periods being affected by small errors.
• Greater difficulty reconciling historical data.
• Increased exposure if records are reviewed.

Many sellers only recognise this once an accountant requests reconciliations, a VAT return does not reconcile cleanly, or HMRC raises a query based on marketplace data. At that point, the cost is no longer the price of software, but the cost of repairing months or years of unreliable records.

Why These Mistakes Matter

Each of these issues is common in isolation. In combination, they create a system where figures appear reasonable but cannot be defended with evidence.

Where sales cannot be reconciled to settlements, VAT cannot be traced to invoices, and inventory figures do not align with operational records, HMRC may question whether the accounting records are sufficiently reliable. At that stage, discussions tend to move away from small adjustments and towards broader control weaknesses.

Avoiding these mistakes is less about choosing a particular software brand and more about using accounting systems in a way that reflects how Amazon actually operates.

10. How to Choose the Right Accounting Software (Decision Framework)

Choosing accounting software for an Amazon business is not about features or brand names. It is about whether your system can turn Amazon’s settlement-based data into UK-compliant accounting records that reconcile to the bank, support VAT reporting, and remain workable as volume increases.

Amazon does not behave like a card terminal or a typical ecommerce checkout. Sales, fees, refunds, reimbursements, reserves, and other adjustments are grouped into settlements and paid days or weeks after the underlying activity. That timing often cuts across month ends, VAT quarters, and accounting periods.

A practical decision framework rests on three principles:

• Data integrity: gross sales, refunds, fees, and adjustments are visible, traceable, and reconcilable.
• UK compliance: VAT reporting and record keeping are supported by a clear audit trail, using functional compatible software and digital links where required. VAT Notice 700/21 explains the record-keeping expectations, including digital records, digital links, and the importance of VAT invoices as evidence for input tax.
• Scalability: the system still closes cleanly when order counts rise, more marketplaces are added, or currencies change.

This section is designed to help you move from research to action and choose a stack that will still work a year from now.

For a complete structural overview of Amazon settlements, VAT logic, inventory treatment, and reporting architecture, see Amazon Seller Accounting – Complete Guide.

Questions to Ask Before Choosing

Before committing to any accounting software or integration, it is prudent to be able to answer the following questions clearly.

1. Can the software handle Amazon settlement data properly?

Amazon settlement reports contain more than a payout figure. They typically include gross sales, refunds, multiple fee types, VAT on fees, marketplace-handled tax in relevant scenarios, reimbursements, and timing differences between transaction dates and payout dates.

Your system would typically need to be capable of recording, at a minimum:

• Gross Amazon sales separately from fees
• Refunds that reverse sales appropriately
• Amazon referral, fulfilment, storage, and advertising fees as expenses
• VAT on Amazon fees where Amazon issues VAT invoices that support recovery (if you are VAT registered and the cost relates to taxable supplies)
• Reimbursements for lost or damaged inventory in a way that does not inflate turnover
• Settlement periods that do not align with payout dates, without collapsing everything into net cash

If the software cannot clearly show how a settlement breaks down into these components, reliability may reduce as volume increases, and evidencing figures may become more difficult if HMRC asks how a VAT return or turnover figure was derived.

2. Does the workflow support clearing-account reconciliation?

A clearing account is the control point that allows Amazon activity to reconcile to the bank without distorting revenue.

Settlement data is typically posted to a dedicated Amazon clearing account (or Amazon receivable). When the payout reaches the bank, it clears that balance.

At month end, the clearing account would ordinarily reconcile to the expected position, often nil, with any remaining balance explained by timing items such as unsettled settlements, reserves held, or in-flight adjustments.

From an enquiry perspective, this matters because it creates a clear bridge from Amazon records to bank receipts and to the ledger, which supports the record-keeping expectations set out in VAT Notice 700/21.

3. Does the stack support your VAT reality?

VAT outcomes for Amazon sellers depend on facts, including where goods are held, where customers are, the nature of the supply, and whether Amazon is responsible for collecting VAT in a particular scenario.

In practice, UK Amazon sellers commonly encounter combinations of:

• UK domestic VAT accounting (standard-rated and zero-rated supplies)
• VAT on Amazon fees, supported by Amazon VAT invoices (relevant to input VAT recovery where permitted)
• Marketplace-facilitator or deemed supplier treatments in relevant cases (where Amazon may collect VAT on certain sales)
• EU consumer sales reporting (for sellers registered for OSS)
• Reverse charge services (commonly relevant to some overseas service providers, depending on supplier location and the service)

The software should allow these to be handled consistently and evidenced through source documentation and digital records, rather than relying on repeated manual overrides.

4. Can you prove it records gross vs net correctly?

A simple test is to post a sample settlement and run a profit and loss report.

If £20,000 of gross sales with £3,500 of fees and £500 of refunds results in £16,000 showing as revenue, the system is wrong. Turnover should reflect gross sales, with fees shown separately as expenses.

If the system only shows the net payout, it is masking data rather than accounting for it. That also increases risk that reported turnover and VAT return figures cannot be explained by reference to Amazon settlement records and supporting invoices if queried.

5. Are integrations optional or mandatory?

Most sellers discover too late that “works with Amazon” does not mean “handles settlements properly”.

Ask directly:

• Does the software import Amazon settlements via API or structured settlement imports (rather than relying on bank feeds as the source of sales)?
• Does it preserve references to settlement IDs or periods so postings can be traced back to Amazon reports?
• Does it maintain digital links or a defensible audit trail from source data to VAT reporting outputs where required?

If the answer to several of these is no, an integration tool such as A2X or Link My Books may become a practical necessity rather than an optional enhancement.

6. Will it scale as order volume increases?

Scalability is about how the system behaves under load.

Ask how long month-end reconciliation takes at higher volumes, whether reporting slows down materially, and whether multi-currency settlements can be handled without repeated manual work. If performance degrades sharply as volume increases, the system will fail when you need it most.

Red Flags Your Setup Isn’t Working

Some systems appear to function but are structurally broken. Common red flags include:

• You cannot reconcile Amazon to the bank without manual “plug” entries.
• Revenue figures change month to month without a clear operational reason.
• VAT returns require manual adjustments every quarter to “make them look right”, rather than being driven by properly coded transactions and supporting records.
• A clearing account exists but never reconciles cleanly to an explainable position.
• You rely heavily on manual journals to “fix” results.
• Month-end close takes longer every quarter as volume grows.

These issues usually indicate that Amazon data is being netted, mis-mapped, or corrected after the fact rather than accounted for correctly at source.

When to Upgrade Your Software Stack

Sellers often delay upgrades because the software still appears to work. The economic reality is that staying too long on an inadequate setup is usually more expensive than upgrading.

Upgrade pressure typically appears when:

• You approach the current VAT registration threshold (a rolling 12-month test).
• Monthly transaction volume makes reconciliation take more than an hour.
• You add a second sales channel such as Shopify or eBay.
• You begin selling in multiple currencies or EU marketplaces.
• The cost of corrections and accountant clean-up exceeds the cost of better software.

For multi-currency or EU sales, figures generally need to be translated into sterling for UK reporting and VAT purposes. A consistent GBP conversion method should be used, such as transaction-date rates, with the basis retained so amounts can be evidenced from source reports.

Delayed upgrades increase clean-up costs, extend HMRC exposure if errors accumulate across multiple VAT periods, and make future migrations harder.

When to Speak to an Amazon Accountant

Software alone cannot solve every problem. Professional support becomes important when:

• Reconciliation issues persist despite using integrations.
• VAT figures cannot be reconciled back to Amazon data and supporting VAT invoices.
• You operate across multiple VAT regimes or channels and need consistent treatment and documentation.
• Inventory and reimbursements do not reconcile to Seller Central and your year-end inventory position cannot be evidenced cleanly.
• You want assurance that your records, reconciliations, and VAT working papers are enquiry-ready.

An Amazon-experienced accountant can distinguish between software limitations and process errors, design an appropriate chart of accounts, validate VAT logic in the context of your fact pattern, and confirm that your system produces defensible records supported by the types of evidence HMRC expects to see.

Early involvement can, in many cases, cost less than historical clean-up after errors have compounded.

Locked-In Position

Choosing accounting software for Amazon is a structural decision, not a cosmetic one. The right stack allows you to explain, with evidence, how turnover, VAT, and cash movements were produced from Amazon settlement reports, invoices, and reconciliations. VAT Notice 700/21 sets out the importance of keeping complete records and maintaining digital records and links where required.

This framework is intended to help you choose once, choose properly, and avoid rebuilding later.