How Stripe Fees Are Treated in Accounting

Last updated: March 2026

Stripe fees can seem straightforward, but their accounting treatment under UK GAAP (FRS 102) and HMRC rules is often misunderstood by ecommerce sellers. In this guide, we explain how Stripe fees interact with turnover, VAT reporting (including the reverse charge), and profit calculations for businesses selling through Stripe, Amazon, and Shopify.

By the end, you’ll have a clearer understanding of how Stripe activity is commonly recorded in UK ecommerce accounting, and how it fits within broader bookkeeping and VAT reporting processes.

Contents

~55–65 min read · Updated February 2026

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

• Introduction: Why Stripe Fees Cause Accounting Confusion
• What Are Stripe Fees?
• Gross vs Net Revenue: The Core Accounting Principle
• Where Stripe Fees Appear in Accounting Software
• VAT on Stripe Fees (UK Treatment Explained)
• Reconciling Stripe Payouts to Your Bank Account
• Stripe vs Amazon vs PayPal: Accounting Differences
• Stripe Reporting Tools and Data Sources
• Common Stripe Accounting Mistakes
• Stripe Accounting FAQs
• Action Step: Download the Stripe Reconciliation Checklist

1. Introduction: Why Stripe Fees Cause Accounting Confusion

Stripe is often the first payment processor UK ecommerce sellers use outside of marketplace platforms like Amazon. It integrates easily with Shopify and other direct-to-consumer setups and gives sellers fast access to customer payments. Despite this apparent simplicity, Stripe is one of the most common sources of accounting errors once transaction volumes increase.

The confusion does not usually arise because Stripe data is unclear. It arises because Stripe behaves very differently from a bank account, while many sellers record it as if it were one. Stripe collects customer payments, deducts its fees, manages refunds and disputes, and then pays out net amounts to the seller’s bank. The cash received therefore does not usually map neatly to sales revenue, and treating net payouts as sales can lead to misstated turnover and margins.

Stripe accounting issues tend to surface later, often when VAT returns are reviewed, margins stop making sense, or an accountant attempts to reconcile reported turnover to bank receipts. By that stage, errors are often embedded across multiple reporting periods, making them harder to unwind cleanly.

For the wider framework (Amazon settlements, Shopify/Stripe flows, VAT, and reconciliations), see Amazon Seller Accounting – Complete Guide.

Why Stripe payouts rarely match sales totals

Stripe does not pay out the full amount a customer pays at checkout. It deducts transaction fees, refund costs, and dispute charges before releasing funds to the seller. In addition, Stripe may hold funds temporarily before payout.

In the UK, Stripe typically operates on a variable payout schedule rather than a fixed settlement rule. Payouts commonly occur on a T+2 to T+7 basis, often around T+3 for many established accounts, but this varies depending on account history, risk profile, and payout settings. As a result, sales made in one period may be paid out in a later period.

From an accounting perspective, this timing difference is expected. Under UK accounting standards, revenue is generally recognised by reference to when the sale is made and the underlying obligations are met, rather than when cash is received, subject to the specific facts and accounting methods applied by the business. Stripe payouts therefore may not reconcile directly to sales totals for a given month. When sellers assume they should, accounting distortions typically follow.

The most common Stripe accounting mistakes

The most frequent error is posting Stripe payouts directly to sales income. This records revenue net of fees rather than at gross value, which can understate turnover and distort reported gross margin.

A second common mistake is treating Stripe fees as negative revenue rather than as operating expenses. Stripe fees are costs of processing payments and, in a typical principal-style ecommerce sale, they do not change the value of the sale made to the customer.

• Mixing Stripe payouts with Amazon settlements in a single bank feed without separation
• Failing to account for refunds and chargebacks in the correct period
• Ignoring VAT treatment on Stripe fees altogether
• Relying on bank deposits as the primary source of truth

These issues often remain unnoticed until VAT registration, a compliance review, or a full reconciliation is attempted.

Who this guide is for (Amazon, Shopify, hybrid sellers)

This guide is written for UK ecommerce sellers who use Stripe as part of their payment stack and want their accounting to reflect commercial activity rather than cash movement alone.

• Shopify-led businesses using Stripe as their primary payment processor
• Amazon sellers who also sell direct-to-consumer
• Hybrid sellers reconciling Amazon settlements alongside Stripe payouts
• Businesses approaching the VAT threshold or already VAT registered
• Sellers using Xero or QuickBooks who want clean, defensible reconciliations

The purpose of this article is not to explain Stripe’s interface or pricing. It is to explain how Stripe fits into UK accounting logic so that revenue, fees, VAT, and bank balances all line up cleanly and continue to do so as the business scales.

2. What Are Stripe Fees?

Stripe fees are charges levied by Stripe for providing payment processing services. From an accounting perspective, these fees represent service costs incurred to collect customer payments, not adjustments to sales revenue. This distinction is fundamental for UK ecommerce sellers, particularly those selling through Amazon alongside direct-to-consumer channels such as Shopify.

A recurring source of confusion is that Stripe deducts its fees before paying funds out to the seller’s bank account. This creates a misleading impression that the net payout represents revenue. In most standard UK ecommerce accounting scenarios, this is not the case. Revenue is measured by the gross value paid by the customer, while Stripe fees are treated as operating expenses incurred to facilitate the transaction.

Understanding the individual components of Stripe’s fee structure helps sellers record transactions accurately, reconcile payouts cleanly, and avoid errors that can affect VAT returns, management accounts, and year-end financial statements.

Stripe transaction fees explained

The core Stripe fee is the transaction processing fee charged each time a customer payment is successfully processed. For UK-based Stripe accounts accepting UK cards, this fee is typically calculated as a percentage of the transaction value plus a fixed per-transaction amount.

In practical terms, when a customer pays £100 through Stripe, Stripe processes the card payment, performs fraud checks, settles funds through the card networks, and credits the seller’s Stripe balance. The processing fee represents Stripe’s charge for providing that service. The seller’s accounting records should normally reflect:

• £100 as gross sales revenue
• The Stripe transaction fee as a payment processing expense

This mirrors the accounting treatment used for Amazon referral fees or FBA fees. The existence of a net payout does not change the underlying revenue figure. HMRC guidance and UK accounting standards focus on the value paid by the customer, not the amount remitted after payment processing costs.

This principle is especially important for VAT threshold monitoring. VAT registration is tested against taxable turnover based on gross sales, not net receipts. HMRC’s VAT registration rules (including the rolling 12-month test and what counts as taxable turnover) are set out in VAT Notice 700/1. Sellers who rely on Stripe payouts as a proxy for turnover often understate their true revenue position.

Fixed vs percentage-based fees

Stripe’s standard transaction fee structure combines two elements:

• A percentage-based fee, calculated as a percentage of the transaction value
• A fixed fee, charged per transaction regardless of value

For example, on a £100 transaction, Stripe may charge a percentage fee plus a fixed amount such as £0.20. The percentage component scales with transaction size, while the fixed fee has a disproportionate impact on lower-value transactions.

From an accounting perspective, both elements are treated in the same way. They are recorded together as payment processing costs within operating expenses. There is no accounting basis for netting either component against revenue.

For ecommerce businesses processing a high volume of low-value transactions, the fixed fee can materially affect margins. This is not a VAT or accounting compliance issue, but it does influence commercial analysis and pricing decisions. Proper fee visibility in the profit and loss account allows sellers to assess true contribution margins by channel and payment method.

Currency conversion and cross-border fees

Stripe charges additional fees where transactions involve non-UK cards or non-GBP currencies. These costs typically arise for two reasons:

1. Cross-border card processing, where the customer’s card is issued outside the UK or EEA
2. Currency conversion, where the customer pays in a currency different from the seller’s Stripe settlement currency

The accounting treatment remains consistent. The full amount paid by the customer is recognised as gross revenue at the applicable exchange rate on the transaction date. Any additional Stripe fees, including currency conversion charges and cross-border processing fees, are recorded as expenses.

Currency conversion introduces an additional layer of complexity. Where Stripe converts foreign currency receipts into GBP before payout, exchange rate movements can create gains or losses between the transaction date and settlement date. These amounts are typically treated separately from Stripe’s service fees and should be identified distinctly where material.

For UK ecommerce sellers with international customers, failure to separate transaction fees from foreign exchange effects is a common cause of reconciliation issues and unexplained differences between sales reports and bank deposits.

Disputes, chargebacks, and refund fees

Stripe applies separate fees when transactions are disputed, charged back, or refunded. These charges are not penalties in an accounting sense. They represent additional service costs for handling dispute processes through card networks and issuing banks.

When a chargeback occurs, two financial effects usually arise:

• The original transaction amount is temporarily or permanently reversed
• Stripe charges one or more dispute-related service fees

From an accounting standpoint, these elements should be treated separately. The reversal of the sale affects revenue, typically through a sales returns or contra-revenue account. The Stripe dispute fees are operating expenses, similar in nature to transaction fees, and are often tracked separately for management visibility.

Refunds introduce another common misunderstanding. While the customer receives their payment back, Stripe typically retains the original processing fee. This means the seller loses both the sale value and the associated fee. The retained fee is not reversed against revenue. It remains an expense of the business.

For UK ecommerce sellers, particularly those with higher return rates, this leads to an increase in effective payment processing costs. Correct accounting treatment ensures this impact is visible and does not distort reported revenue figures.

3. Gross vs Net Revenue: The Core Accounting Principle

One of the most common accounting errors made by UK ecommerce sellers using Stripe is confusing net payouts with revenue. Stripe deposits the net amount after fees, but where a UK ecommerce business is acting as principal in the sale, UK accounting standards and HMRC guidance generally support recording revenue at the gross value paid by the customer.

Understanding this distinction is critical for VAT compliance, Corporation Tax reporting, and defending figures during an HMRC enquiry. Although Stripe, Amazon, PayPal, and Shopify all use different settlement mechanics, the underlying accounting treatment is the same in a standard UK ecommerce setup where the seller controls pricing and the customer relationship. In a typical principal-based ecommerce model, the customer payment represents turnover. Platform or processor fees are costs of doing business, not reductions of revenue.

What HMRC considers turnover

HMRC applies a broad and consistent definition of turnover. It is the total value of sales made by a business in the course of its trade, before deducting expenses such as payment processing fees, marketplace commissions, or fulfilment costs.

For VAT purposes, this definition underpins both VAT return reporting and the VAT registration threshold. Taxable turnover is based on the value of taxable supplies made by the business, measured at the point of supply, rather than on the cash ultimately received after deductions. This is why HMRC guidance and VAT Notices consistently refer to the “value of the supply” rather than net receipts. See HMRC’s VAT guide (VAT Notice 700) for the framework that underpins VAT reporting and record trails.

A similar gross presentation approach is typically reflected in accounts prepared for Corporation Tax and Income Tax purposes. UK accounts prepared under FRS 102 start with gross turnover, with expenses shown separately. Payment processor fees reduce profit, not revenue.

In practical terms, when a customer pays £100 through Stripe, the business’s turnover is £100, even though Stripe later deducts its fees before paying funds into the bank account. Stripe’s charges are allowable business expenses. They are not a contra-revenue item.

HMRC also expects businesses to retain evidence that supports this gross figure. For Stripe users, this normally includes transaction-level reports, balance summaries, and reconciliation schedules that clearly separate gross customer payments, fees, and net payouts. These records allow HMRC to follow the audit trail from customer payment, to Stripe activity, to bank deposits.

This approach mirrors HMRC’s treatment of Amazon marketplace sales. Even though Amazon pays sellers net of referral fees, fulfilment charges, and other deductions, HMRC still treats the customer’s full purchase price as turnover for VAT and tax purposes.

Why Stripe pays net but reports gross

Stripe acts as a payment processor, not as the seller of record. The merchant remains the party making the supply to the customer. Stripe’s role is to collect funds on the merchant’s behalf, deduct its agreed fees, and remit the remaining balance.

Operationally, this results in net bank deposits, which is where confusion often begins. However, Stripe’s internal reporting typically shows gross transaction values alongside itemised fees. The gross figure represents the consideration paid by the customer. The fee lines represent Stripe’s service charges.

Stripe settles on a net basis for practical reasons rather than accounting ones. Funds are retained to cover processing fees, refunds, chargebacks, card network requirements, and timing differences between transactions and payouts. Net settlement simplifies cash management and risk control for Stripe, but it does not change the accounting position of the merchant.

From an accounting perspective, Stripe’s gross transaction data is generally the appropriate source for revenue recognition. Bank feeds show cash movement, not economic activity, which is why revenue should not be derived from bank deposits alone.

Example: £10,000 of sales and a £9,700 payout

Consider a UK limited company that processes £10,000 of customer payments through Stripe in a single month. Stripe charges £300 in transaction fees and pays £9,700 into the company’s bank account.

• Revenue: £10,000
• Stripe fees (expense): £300
• Net cash received: £9,700

The £9,700 payout reconciles to the bank account, but it does not represent turnover. The turnover figure would normally remain £10,000 for accounting purposes and, where applicable, would feed into VAT reporting (including Box 6) and tax computations, subject to the VAT scheme and specific supply analysis. The example assumes the £10,000 represents net-of-VAT taxable sales for explanatory purposes.

This same logic applies when reconciling Amazon settlements, where net payouts often differ significantly from gross sales due to multiple layers of fees, refunds, and timing adjustments.

Why net reporting understates revenue

Recording only net Stripe payouts as revenue will systematically understate turnover. While profit may sometimes appear similar if fees are omitted elsewhere, the wider consequences are significant.

• VAT registration threshold monitoring, which is based on rolling 12-month gross taxable turnover
• VAT returns, particularly Box 6 values
• Companies House filings, where turnover influences company size thresholds
• HMRC risk profiling, as bank deposits no longer align with expected fee patterns

If Stripe fees are incorrectly treated as cost of goods sold rather than operating expenses, reported gross margin becomes structurally misleading. For a detailed explanation of what does and does not belong in COGS for Amazon and multi-channel sellers, see Inventory & Cost of Goods Accounting for Amazon.

Over time, even relatively small percentage differences compound. The result is growing discrepancies between platform data, accounting records, and filed returns. These inconsistencies are the type HMRC’s automated systems and compliance officers commonly investigate.

Impact on VAT and Corporation Tax

For VAT-registered businesses, gross versus net reporting directly affects VAT declarations. VAT on sales is calculated on the value of the supply to the customer, subject to the VAT accounting scheme used. Using net figures can therefore lead to under-declared outputs and incorrect treatment of Stripe fees under the reverse charge mechanism.

For Corporation Tax, the final taxable profit may sometimes appear similar where both revenue and expenses are understated. However, the audit trail is weakened. HMRC expects revenue, expenses, and bank movements to reconcile logically. Where revenue is understated and fees are not clearly disclosed, that reconciliation breaks down, increasing the likelihood of follow-up questions or a formal enquiry.

Gross revenue reporting in principal-based ecommerce models is not merely a presentation preference. It is the foundation that allows Stripe activity to reconcile cleanly across accounting records, VAT returns, tax computations, and bank statements in a way that is defensible under HMRC review.

4. Where Stripe Fees Appear in Accounting Software

When Stripe is connected to accounting software, most problems do not arise because the data is missing. They arise because the data is mapped to the wrong place. Stripe deposits net amounts, but accounting systems need to reflect gross revenue, separate fees, and timing differences in a way that can be supported by underlying evidence and explained clearly to HMRC.

This section explains where Stripe fees typically sit in the chart of accounts, how they interact with revenue, and why the setup matters for Amazon-led, Shopify-led, and hybrid UK ecommerce businesses. If you are choosing between Xero and QuickBooks, prioritise whichever lets you run a clean Stripe clearing account, correct VAT codes for reverse charge fees, and transparent fee reporting — see Best Accounting Software for Amazon Sellers (UK).

Stripe fees as operating expenses

Under UK GAAP (FRS 102), Stripe fees are typically treated as operating expenses where the business is acting as principal in the sale. They are not reductions to revenue and they are not cost of sales in the traditional sense, unless the business deliberately presents them that way as part of a consistent and clearly documented accounting policy.

In practice, Stripe fees usually sit within administrative or selling expenses, alongside other payment processing costs such as PayPal fees or card terminal charges. This treatment reflects the economic reality that Stripe is providing a payment service to the business, rather than acting as a reseller of the goods.

For an Amazon or direct-to-consumer seller, this mirrors the treatment of Amazon referral fees. Even though Amazon deducts its fees before paying sellers, those fees are still expenses, and turnover is recorded at the gross customer price. Stripe operates on the same accounting principle, even though the operational flow feels different.

Placing Stripe fees consistently as operating expenses allows profit margins, payment costs, and channel performance to be analysed accurately without distorting reported turnover, provided the classification is applied consistently period to period.

Separating fees from revenue

One of the most common Stripe mapping errors is allowing net payouts to post directly to revenue. This typically happens when bank feeds are relied on without reference to Stripe’s transaction-level data.

In standard principal-based ecommerce accounting, correct treatment separates three elements:

• Gross customer payments, recorded as revenue
• Stripe fees, recorded as expenses
• Net cash received, recorded to the bank account

If fees are netted off against revenue, turnover is understated. This affects VAT threshold monitoring, Box 6 values on VAT returns, and the ability to reconcile platform data to bank statements. In an HMRC enquiry, businesses would ordinarily be asked to demonstrate how reported revenue is derived from underlying transaction evidence, rather than from net cash movements alone.

Separating fees also makes it easier to demonstrate consistent treatment of Stripe charges and to identify where reverse charge VAT applies to Stripe fees.

Dedicated “Merchant Fees” accounts

It is common practice for UK ecommerce businesses to use a dedicated general ledger account for payment processor fees. This is often labelled “Merchant Fees”, “Payment Processing Fees”, or “Stripe and Card Fees”.

Using a single, clearly named account has several advantages:

• Stripe costs are visible and easy to monitor month by month
• Blended fee rates across Amazon, Stripe, and other platforms can be analysed
• Reconciliation is more efficient because Stripe charges land in one place
• HMRC queries can be addressed using a clear and consistent ledger trail

Some larger sellers choose to split Stripe transaction fees, FX fees, and dispute fees into sub-accounts. This is optional rather than mandatory, but can be useful where cross-border sales volumes or chargeback activity are material to the business.

Clearing accounts vs direct posting

For low-volume Stripe users with simple activity, it may be acceptable to post Stripe transactions directly to the bank account, provided gross sales and fees are imported accurately from Stripe reports and reconciled regularly. This approach relies heavily on materiality and carries higher risk as transaction volumes increase.

For most growing ecommerce businesses, a Stripe clearing account is safer and more defensible. A clearing account acts as a temporary holding account that mirrors Stripe’s internal balance. Customer payments, refunds, fees, and chargebacks flow through the clearing account before settling to the bank.

This structure allows timing differences to be handled cleanly. Pending funds, refunds processed after month-end, and chargebacks that span periods can all be reconciled without forcing inappropriate adjustments into revenue or expenses. At period end, a well-maintained clearing account should reconcile closely to Stripe’s reported balance.

From an HMRC perspective, a clearing account strengthens the audit trail by linking Stripe transaction reports directly to ledger balances and bank deposits.

Common mapping errors in Xero and QuickBooks

Most Stripe accounting issues arise from automation rules that are too simplistic or rely too heavily on bank feeds.

• Posting Stripe payouts directly to sales accounts
• Failing to record Stripe fees in full
• Applying no VAT code to fees, obscuring reverse charge treatment
• Mixing Stripe and Amazon deposits within the same posting rules
• Allowing bank feed rules to override imported Stripe transaction data

Xero users are particularly exposed to net-posting errors because bank feeds are often treated as the primary data source. QuickBooks users more commonly encounter issues with clearing or holding accounts that are not fully reconciled.

Regardless of software, the principle is consistent. Stripe reports should be treated as the primary source of truth for gross sales and fees, with bank feeds used to confirm cash movement rather than to determine revenue.

When this mapping is set up carefully, Stripe activity is more likely to reconcile cleanly and VAT reporting is more likely to align with HMRC record-keeping expectations, allowing Amazon-led sellers to integrate Stripe without weakening their overall accounting framework.

5. VAT on Stripe Fees (UK Treatment Explained)

Stripe fees are a common VAT tripwire for UK ecommerce sellers because Stripe invoices often show £0 VAT. That can look like a VAT-free cost, but in many cases it represents a reverse-charged supply that still needs to be reflected in the VAT return. Where a business is close to VAT registration, this also interacts with wider VAT considerations, including the UK VAT Thresholds Explained rules and HMRC’s definition of taxable turnover.

Is VAT charged on Stripe fees?

Stripe invoices to UK businesses frequently show no UK VAT on transaction fees. That does not automatically mean the service is VAT-exempt or outside the scope of VAT.

For UK VAT-registered businesses, the most common position is that VAT is accounted for using the reverse charge mechanism. In practical terms, this means the VAT is declared on the customer’s VAT return rather than being charged by Stripe on the invoice.

For example, a monthly Stripe invoice may show £2,000 of fees with £0 VAT. Even though no VAT has been charged by Stripe, a VAT-registered UK business may still be required to calculate VAT on that £2,000 and include it in its VAT return.

Whether reverse charge applies depends on the nature of the service supplied and the Stripe contracting entity, which is why Stripe invoices and contractual details should be reviewed as part of VAT setup.

Stripe as a non-UK supplier

Stripe typically supplies payment processing services to UK businesses through a non-UK entity, commonly an Irish Stripe company. For VAT purposes, the key factors are the supplier’s location and where the customer belongs.

Under the general place of supply rules for business-to-business services, the place of supply is usually where the customer belongs. For a UK ecommerce business, that generally means the supply is treated as made in the UK. Where the supplier is established outside the UK and the service is not VAT-exempt, the reverse charge mechanism is the standard method by which VAT is accounted for in the UK.

In practice, Stripe invoices often evidence this position by showing a non-UK VAT number alongside wording such as “VAT to be accounted for by the customer”.

Reverse charge mechanism explained

The reverse charge shifts responsibility for VAT accounting from the supplier to the customer. Instead of Stripe charging VAT and paying it to HMRC, the UK business self-accounts for VAT on the value of the service.

For most VAT-registered ecommerce sellers making fully taxable supplies, the process is typically as follows:

• Output VAT is calculated on the net Stripe fees at the applicable UK rate where the service is standard-rated.
• That VAT is included as output tax on the VAT return.
• The same amount may be reclaimed as input tax, provided the cost relates to taxable business activity and input tax recovery is permitted.

The underlying UK VAT rules for cross-border B2B services (including place of supply) are covered in HMRC VAT Notice 741A.

This can result in a nil net VAT effect for fully taxable businesses, but it remains a formal reporting requirement. HMRC may query missing reverse charge entries even where the overall VAT payable is unchanged.

Where a business is partially exempt, reverse charge VAT on Stripe fees may only be partially recoverable, turning Stripe fees into a genuine VAT cost.

How VAT appears on Stripe invoices

Stripe invoices typically show the net value of fees with £0 VAT, accompanied by wording indicating that the customer may need to account for VAT.

For bookkeeping purposes, it is important to distinguish this from UK supplier invoices that are zero-rated or VAT-exempt. In the Stripe context, “£0 VAT” often indicates that VAT may need to be accounted for through the reverse charge on the VAT return, rather than being charged on the invoice, subject to the nature of the service and the business’s VAT status.

Under HMRC’s VAT record-keeping requirements (VAT Notice 700/22), Stripe invoices and supporting reports should be retained as part of the VAT audit trail and kept in a way that supports digital record-keeping where required. This preserves a clear audit trail from invoice, to accounting records, to VAT return.

Box 1, Box 4, and Box 6 treatment

Where Stripe fees are reverse-charged and the business uses standard VAT accounting, they are commonly reflected in the following VAT return boxes:

• Box 1: Output VAT self-accounted for on the Stripe fees
• Box 4: Input VAT reclaimed on the same amount, where recovery is permitted
• Box 6: The net value of the reverse-charged services, where the accounting system includes such values in Box 6

Depending on VAT codes and software configuration, the net value may also appear in Box 7 as purchases. A useful control is to review VAT return detail in Xero or QuickBooks and check that Stripe reverse charge values are flowing consistently.

What happens if VAT is mapped incorrectly

Stripe VAT errors often go unnoticed because the reverse charge is frequently VAT-neutral. The headline VAT payable figure may still look reasonable even when reporting is wrong.

• Posting Stripe fees as “no VAT” or “outside scope” when reverse charge should apply
• Failing to include reverse charge VAT in Box 1 and Box 4
• Including values in Box 6 without accounting for the VAT element
• Weak digital records, such as missing Stripe invoices or incomplete reconciliations between Stripe reports, bank deposits, and VAT returns

Even where the net VAT impact is small, repeated errors increase HMRC risk and administrative burden, particularly if HMRC requests evidence of overseas services and reverse charge treatment.

6. Reconciling Stripe Payouts to Your Bank Account

Reconciling Stripe payouts is one of the most common pressure points for UK e-commerce sellers, particularly those selling through Amazon, Shopify, or a hybrid setup. The difficulty usually arises because Stripe does not operate like a traditional bank account. Money moves through several internal stages before it ever reaches your business bank account, and those stages matter for accounting, VAT, and HMRC evidence.

This section explains how to reconcile Stripe properly, not just so the numbers appear to agree, but so you can demonstrate clearly and consistently where every pound sits at any point in time.

Stripe balance vs bank deposits

A Stripe balance is not the same thing as cash in your bank account. Stripe maintains an internal balance made up of several components, most commonly:

• Available funds, which are eligible for payout
• Pending funds, which relate to recent card payments still within the settlement window
• Reserved amounts, which may be held temporarily for disputes or risk checks

Your bank statement only shows the net payouts Stripe sends to your bank. It does not show individual customer payments, fees, refunds, or chargebacks. This distinction is where confusion often begins.

For example, an Amazon seller may see £12,000 land in their bank account from Stripe in April, while Stripe reports £14,500 of sales activity for the same period. The difference is not missing income. It is typically explained by Stripe fees, refunds paid directly back to customers, and timing differences between when payments are captured and when payouts are released.

From an HMRC perspective, bank deposits alone are not sufficient evidence of turnover. HMRC would ordinarily expect transaction-level support, such as Stripe transaction reports and reconciliation schedules, that show how gross customer payments reconcile to net cash received, in line with VAT record-keeping requirements.

Timing differences and pending funds

Stripe payouts are made on a rolling schedule, often T+2 or T+3 business days for established UK accounts, although this varies depending on account settings and risk profile. This creates timing differences that are entirely normal but should be handled correctly in the accounting records.

If a customer places an order on 29 March and pays by card, Stripe may capture the payment immediately, but the payout may not reach the bank until early April. In most standard ecommerce cases where the seller acts as principal and goods or services are supplied at that point, the sale is recognised in March rather than April, because that is when the customer is charged and the performance obligation is met.

For VAT purposes, the treatment depends on the VAT scheme in use. Under standard VAT accounting, output VAT is normally due based on the tax point, which for card payments is typically the transaction date, even if funds are still pending in Stripe at the period end. Sellers using the VAT Cash Accounting Scheme differ, as VAT is declared when payment is received, but this is a scheme-specific exception rather than the default position.

This is why pending Stripe balances should still appear in reconciliations and, in many cases, in revenue figures, even though the cash has not yet reached the bank.

Refunds and chargebacks across periods

Refunds and chargebacks are another reason Stripe balances and bank accounts rarely align neatly.

When a refund is issued, Stripe usually sends the funds directly back to the customer’s card. The refund does not pass back through the seller’s bank account. Instead, it is deducted from the Stripe balance immediately or offset against future takings if the balance is insufficient.

Chargebacks operate in a similar way but often involve additional non-refundable dispute fees. From an accounting perspective, both refunds and chargebacks will generally result in revenue being reversed and, where applicable, VAT to be adjusted by reference to the original transaction.

For example, if a March sale is refunded in May, the March bank payout remains unchanged. The correction is made through accounting entries rather than through the bank. This is why relying on bank statements alone leads to reconciliation gaps and increased HMRC risk.

Using clearing accounts for Stripe

A commonly used and robust method of reconciling Stripe activity is to use a dedicated Stripe clearing account in the accounting software.

A clearing account acts as an intermediary between Stripe and the bank account. All Stripe activity flows through it, including:

• Gross customer payments
• Stripe fees
• Refunds and chargebacks
• Net payouts to the bank

In software such as Xero or QuickBooks, this structure separates commercial activity from cash movement. Sales are recorded when they occur, fees are recorded as expenses, refunds reduce revenue, and payouts simply transfer funds from the clearing account to the bank.

This approach allows timing differences, pending balances, and refunds to be handled cleanly and creates a clear audit trail that HMRC can follow from Stripe reports through to the bank statement.

What a “clean” reconciliation looks like

A clean Stripe reconciliation is not just about balances agreeing. It is about being able to explain why they agree.

• The Stripe clearing account balance matches Stripe’s reported balance, including available and pending funds
• Bank deposits match Stripe payout reports exactly
• Fees, refunds, and chargebacks are separately identifiable
• Timing differences are documented and expected
• Revenue and VAT figures are supported by transaction-level reports rather than estimates

For Amazon sellers, this level of clarity becomes particularly important as turnover approaches VAT registration thresholds or when HMRC opens a compliance check.

Reconciling Stripe properly is not about perfection. It is about control, clarity, and being able to demonstrate, quickly and confidently, how Stripe activity translates into reported revenue, VAT, and cash.

7. Stripe vs Amazon vs PayPal: Accounting Differences

This section places Stripe, Amazon, and PayPal side by side from an accounting and HMRC perspective. UK ecommerce sellers often use more than one of these platforms at the same time, which is where problems tend to arise. While the underlying accounting principles are consistent, the mechanics are not. Understanding where they diverge is essential for accurate reporting, VAT compliance, and maintaining records that can be defended if HMRC raises questions.

Settlement model vs payout model

The most important distinction between these platforms is the difference between a settlement model and a payout, or processor, model. This distinction determines what primary evidence exists, how revenue is reconstructed, and how reconciliations are performed.

Amazon operates a settlement model. Sales, refunds, fees, reserves, and adjustments are accumulated within Amazon’s system and released on a fixed settlement cycle, typically every 14 days. The settlement report is the primary accounting document. It shows gross sales, refunds, Amazon fees, VAT elements, reserves held, and the resulting net payout. The bank deposit is simply the final outcome of that settlement process.

Stripe operates a payout model. Each card payment is processed individually, fees are deducted per transaction, and funds are paid out on a rolling basis, commonly T+2 or T+3 business days. There is no single settlement statement that aggregates activity into an authoritative period summary. The accounting evidence therefore sits at transaction level rather than payout level.

PayPal sits between the two models. It can behave like a payment processor with frequent payouts, or like a wallet that holds balances, applies holds, and allows discretionary withdrawals. Because of this hybrid structure, PayPal accounting often borrows elements from both Stripe and Amazon but cannot be treated identically to either.

Why Amazon requires settlement accounting

Amazon’s structure makes settlement accounting unavoidable. Amazon controls the customer relationship, processes refunds and chargebacks, deducts multiple fee types, and may hold reserves for extended periods. Under UK GAAP, including FRS 102, revenue is still recognised when control of goods passes to the customer, but the settlement report is the only practical way to evidence that revenue.

For a UK Amazon FBA seller with £120,000 annual turnover, the settlement report typically becomes the anchor document for HMRC. It supports gross revenue figures, shows VAT collected under marketplace facilitator rules, and explains why bank deposits do not equal sales. Attempting to reconstruct Amazon activity from bank statements alone commonly results in missing reserves, misclassified fees, and incomplete VAT treatment.

For this reason, HMRC would ordinarily expect Amazon sellers to retain settlement reports as part of their records in line with VAT record-keeping requirements. The bank statement confirms cash movement, but the settlement explains the underlying economics.

Why Stripe requires transaction-level accounting

Stripe operates differently. Stripe does not issue settlement statements and does not aggregate sales into fixed accounting periods. The seller remains fully responsible for revenue recognition, refunds, disputes, and VAT.

For Stripe, the transaction itself is the accounting event. In most standard ecommerce cases where the seller is acting as principal, revenue is recognised when the sale occurs, not when the payout reaches the bank. Fees are generally recorded separately as expenses. Refunds and chargebacks often bypass the bank entirely and exist only within Stripe’s transaction data.

For HMRC purposes, this means a Stripe seller should be able to produce transaction-level reports showing dates, amounts, fees, and outcomes where needed to support declared turnover and VAT figures. Bank deposits on their own are not sufficient evidence of turnover. This is why robust Stripe accounting typically uses a clearing account that reconciles transaction totals to payouts. Sellers who post Stripe deposits directly to revenue usually understate turnover and lose visibility of fees and VAT.

If you want a practical walkthrough of how this reconciliation works in practice, see Amazon Payout Reconciliation – Step-by-Step, which explains the same logic from the Amazon side and highlights why Stripe requires a different workflow.

PayPal fee treatment differences

PayPal introduces a further layer of complexity. Many core PayPal payment processing fees are treated as VAT-exempt financial services under UK VAT legislation, meaning there is typically no input VAT to recover on those fees, even for VAT-registered businesses. However, not all PayPal charges are identical, and some ancillary or non-payment services may carry different VAT treatment.

From an accounting perspective, this makes it important to separate PayPal fees from Stripe and Amazon fees in the chart of accounts. Mixing them together makes it difficult to determine which fees carry recoverable VAT and which do not. For hybrid sellers using Amazon, Stripe, and PayPal, this is a common source of VAT errors that often only surface during an HMRC review.

PayPal’s wallet functionality also means balances may sit off-bank at period end. In those cases, PayPal balances should appear on the balance sheet as current assets, often split between available and held amounts. Treating PayPal like Stripe, where balances usually clear quickly, risks misstating liquidity.

When accounting logic overlaps, and when it doesn’t

Despite these operational differences, the underlying accounting logic is consistent. All three platforms are subject to the same UK GAAP revenue recognition framework, with the specific treatment depending on whether the seller is acting as principal or agent. Revenue is recorded gross where the seller is principal, fees are treated as expenses, and timing is driven by when goods or services are supplied rather than when cash is received.

Where logic overlaps:

• Gross revenue is generally reported on a consistent basis
• Fees are typically recorded separately from revenue
• VAT on sales follows the same statutory rules, even where collection mechanics differ
• HMRC would ordinarily expect a clear audit trail from source data to the general ledger and then to the bank

Where logic diverges:

• Amazon relies on settlement reports as primary evidence
• Stripe relies on transaction-level data and clearing accounts
• PayPal may require balance sheet recognition of held funds and careful consideration of VAT-exempt fee treatment

For UK ecommerce businesses, particularly Amazon sellers expanding into direct-to-consumer channels, these distinctions are not academic. They determine whether records stand up to HMRC scrutiny, whether VAT returns are accurate, and whether reported revenue reflects the true scale of the business.

8. Stripe Reporting Tools and Data Sources

Stripe provides a wide range of reports, dashboards, and data exports. For UK ecommerce sellers, particularly those running Amazon alongside direct-to-consumer sales, the challenge is not access to data but understanding which reports are relevant for accounting, VAT, and HMRC enquiries. Many sellers download summary views, rely on dashboard totals, or assume their accounting software integration replaces Stripe’s native exports. That assumption is often what causes reconciliation issues later.

This section explains the core Stripe reporting tools that support compliant UK accounting, how each report fits into the bookkeeping and VAT workflow, and which reports are commonly relied upon as supporting evidence if Stripe activity is reviewed by HMRC.

Stripe balance and payout reports

Stripe balance and payout reports sit at the centre of any Stripe reconciliation. Together, they explain how Stripe moves from gross customer payments to cash deposited into your bank account.

The balance report shows Stripe’s internal liability to you at a point in time. It tracks the opening balance, all activity during the period, and the closing balance. Importantly, it separates funds that are available for payout from funds that are pending. Pending balances typically arise from card settlement timing, risk holds, refunds in progress, or disputes.

From an accounting perspective, this report supports the Stripe clearing account in your general ledger. Where the accounts show a Stripe balance at month end, the balance report is the document ordinarily used to evidence that figure. Bank statements alone cannot do this, because they only show payouts, not amounts still held by Stripe.

The payout reconciliation report explains how funds move from Stripe to your bank account. It lists each payout, the date it was initiated, the net amount paid, and the destination bank account. This report allows Stripe activity to be matched directly to bank deposits.

For example, an Amazon seller running a Shopify site with Stripe might see £45,000 deposited in January, while Stripe reports £48,000 of activity for the same period. The payout report explains the £3,000 difference as pending funds that will be paid out in February. Without this report, that difference can appear as unexplained income or missing cash.

Taken together, the balance and payout reports allow a business to demonstrate that:

• Gross revenue has been generated
• Fees have been deducted by Stripe
• The remaining funds have either been paid out or are still held at period end

Transaction-level exports

Transaction-level exports are the most important Stripe data source from an HMRC evidence perspective. These exports list every charge, refund, dispute, and adjustment, including dates, amounts, currencies, and transaction IDs.

HMRC does not generally treat net bank deposits alone as sufficient evidence of turnover. Turnover is based on gross consideration received from customers. Stripe’s transaction-level exports are the records that allow gross sales to be reconstructed and verified. They enable an inspector to trace individual customer payments, confirm totals, and check that refunds and chargebacks have been handled correctly.

Transaction-level data also resolves timing issues. Stripe may pay out a transaction several days after the sale occurs, but for accounting and VAT purposes, the transaction date is typically the relevant reference point. Without transaction-level detail, income is often recorded in the wrong period, distorting both management accounts and VAT returns.

For sellers trading in multiple currencies, these exports are essential. They show the presentment currency, the converted GBP amount, and the exchange rate applied. This information is required to identify foreign exchange gains or losses and to reconcile non-GBP sales to a UK bank account.

Fee and tax reports

Stripe’s fee and tax reports support expense classification and VAT accuracy. They break down Stripe’s charges into processing fees, dispute fees, and currency conversion costs. These categories can have different VAT treatments and should not be grouped without review.

For UK VAT-registered sellers, fee reports are often used as the starting point when considering reverse charge VAT treatment. Stripe frequently invoices UK businesses from a non-UK contracting entity, in which case UK VAT is not charged on the invoice and the customer may need to account for VAT under the reverse charge, depending on the specific facts and VAT status of the business. It is the value of the service shown in these reports, rather than the net payout amount, that feeds into VAT reporting, subject to the VAT scheme and software configuration used.

Relying on estimates derived from net payouts creates risk. Fee reports provide primary evidence of what Stripe actually charged, which is what HMRC will usually refer to if VAT recovery or expense deductions are questioned.

Stripe’s own documentation on available reports is published here:
https://stripe.com/docs/reports

What to download monthly (minimum set)

For most UK ecommerce sellers, including Amazon sellers using Stripe for direct sales, a consistent minimum monthly reporting set is sufficient to remain audit-ready.

At month end, it is good practice to retain:

• The Stripe balance summary report
• The Stripe payout reconciliation report
• The full transaction-level payments export
• Where VAT-registered, the Stripe fees or tax report

Together, these documents allow the general ledger to be reconciled, differences between revenue and cash to be explained, VAT to be calculated accurately, and HMRC enquiries to be answered with clear supporting evidence.

The key principle is consistency. Download the same reports for the same date ranges each month, store them digitally, and ensure accounting entries can be traced back to those files. This is the standard HMRC looks for when reviewing platform-based sales and the difference between a reconciliation that can be explained and one that fails under scrutiny.

9. Common Stripe Accounting Mistakes

Stripe is widely used by UK ecommerce businesses, both alongside Amazon and for direct-to-consumer sales. Despite this, Stripe activity is one of the most frequent sources of accounting errors identified when reviewing records for Amazon and multi-channel sellers. These mistakes are rarely deliberate. They usually arise because Stripe payouts feel like “sales”, while the underlying transaction-level data sits elsewhere.

HMRC does not assess compliance solely on commercial intuition. It assesses whether turnover, VAT, and expenses are recorded in accordance with UK GAAP and VAT legislation, and whether those figures are supported by appropriate records. The issues below commonly lead to VAT inaccuracies, distorted profit figures, and increased scrutiny during HMRC reviews. In many cases, sellers only become aware of them when reconciliations fail or when HMRC requests further information.

Posting Stripe payouts as revenue

The most common Stripe accounting mistake is posting net Stripe payouts as turnover. Stripe pays sellers the balance remaining after deducting processing fees, refunds, and chargebacks. That net payout represents a cash settlement, not the value of sales made to customers.

Under UK accounting standards, turnover is measured at the gross amount paid by the customer, net of VAT but before expenses. Stripe’s fees are operating expenses, not reductions of revenue. When payouts are posted as revenue, turnover is understated, often by 2 to 5 percent depending on fee levels.

This creates several downstream issues. VAT registration threshold monitoring becomes unreliable because taxable turnover is understated. Corporation Tax computations start from an incorrect turnover figure, even where the resulting profit may appear broadly similar. Most importantly, reported revenue no longer reconciles to Stripe’s transaction-level data, which is commonly requested by HMRC to corroborate declared figures during enquiries.

Ignoring reverse charge VAT

Stripe commonly supplies payment processing services to UK businesses from outside the UK, most often through its Irish entity, depending on the seller’s specific Stripe contracting entity. For UK VAT-registered businesses, this means many Stripe processing and currency conversion fees fall within the reverse charge mechanism.

Where reverse charge VAT is not accounted for, VAT returns do not reflect the required treatment, even if the net VAT payable position is unchanged. HMRC expects reverse charge services to be self-accounted for and reported correctly on the VAT return.

This issue is particularly significant for partially exempt businesses, where input VAT recovery is restricted. In those cases, reverse charge VAT on Stripe fees can represent a genuine cost. Even for fully taxable Amazon sellers, repeated omission can indicate weak VAT controls, increasing the likelihood of further HMRC review.

Mixing Stripe and Amazon deposits

Stripe and Amazon operate fundamentally different settlement models. Amazon issues settlement statements that aggregate sales, refunds, fees, and VAT over a defined period. Stripe operates on a transaction-level basis, with rolling balances, pending funds, and payouts that do not align neatly to accounting periods.

When Stripe payouts and Amazon settlements are mixed within the same posting rules or ledger accounts without separation, reconciliation becomes more difficult. Channel-level performance analysis is obscured, and it becomes harder to evidence which revenue relates to Amazon marketplace activity and which relates to direct sales. This blurring of the audit trail can complicate responses to HMRC queries.

Clean accounting requires Stripe and Amazon activity to be tracked separately, even where funds ultimately arrive in the same bank account.

Not reconciling refunds properly

Refunds in Stripe do not always occur in the same accounting period as the original sale. A transaction captured in March may be refunded in April, while the related cash impact may occur later depending on payout timing.

If refunds are simply netted against payouts without being separately recorded, revenue figures become distorted across periods and VAT adjustments may be missed or applied incorrectly. Over time, this creates unexplained differences between Stripe reports, VAT returns, and the general ledger.

For VAT and audit purposes, refunds and chargebacks need to be traceable back to the original transaction, with clear links between revenue adjustments, VAT treatment, and cash movements.

Letting Stripe balances drift

Stripe maintains internal balances comprising available funds, pending funds, and, in some cases, reserves. Where these balances are not reconciled regularly, differences can accumulate without explanation.

A drifting Stripe balance often points to missing transactions, unrecorded fees, or unresolved timing differences. From an HMRC perspective, unexplained balances suggest weak record-keeping and control. From a commercial perspective, they create uncertainty over what cash should exist and why it does not.

Regular reconciliation between Stripe balances, the general ledger, and bank deposits is essential to prevent these issues from compounding.

Relying on bank feeds alone

Bank feeds show cash movements, not the underlying economic activity. When sellers rely solely on bank feeds to drive their accounting, Stripe fees are absorbed into net deposits, refunds lose context, and revenue timing becomes unreliable.

In practice, HMRC will typically request platform and processor reports to support declared turnover and VAT figures. Stripe balance summaries, transaction-level exports, and fee reports are commonly relied upon to evidence gross sales and fee treatment.

Bank feeds should support accounting records, not replace them. When they become the primary source of truth, the ability to evidence turnover and VAT accurately is weakened, increasing compliance risk.

10. Stripe Accounting FAQs

This section addresses the most common Stripe accounting questions raised by UK ecommerce and Amazon sellers. Each answer reflects current HMRC guidance, UK GAAP (FRS 102), and established practice used by professional ecommerce accountants when preparing VAT returns, statutory accounts, and HMRC enquiry responses.

Are Stripe fees tax deductible?

Yes. Stripe fees are generally allowable business expenses for UK sole traders and limited companies, provided they are incurred wholly and exclusively for the purposes of the trade.

This typically includes:

• Transaction processing fees, including percentage and fixed components
• Currency conversion and cross-border processing fees
• Refund processing fees retained by Stripe
• Dispute and chargeback fees
• Fees for additional Stripe services, such as Billing or Connect

For Corporation Tax purposes, these costs are treated as operating expenses and deducted when calculating taxable profit. There are no specific HMRC exclusions that apply to Stripe fees themselves. As with any expense, the fees should be supported by appropriate evidence, such as Stripe fee reports or invoices, and correctly recorded in the accounting records.

For example, if a UK limited company generates £120,000 in Stripe-processed sales and incurs £3,600 in Stripe fees, those fees reduce taxable profit by £3,600. At the applicable Corporation Tax rate for the company, this would reduce the tax payable proportionately.

Does Stripe charge VAT in the UK?

Stripe does not usually charge UK VAT on its fees to UK business customers.

In most cases, Stripe supplies payment processing services through a non-UK entity, commonly its Irish company, depending on the specific contracting entity linked to the Stripe account. Under UK VAT rules, this means the supply is treated as a cross-border business-to-business service rather than a domestic UK supply.

As a result:

• Stripe invoices often show £0 VAT
• The invoice typically includes wording indicating that the reverse charge may apply
• Responsibility for accounting for VAT shifts to the UK customer rather than Stripe

Where foreign VAT, such as Irish VAT, is charged, this often indicates that a valid UK VAT number has not been provided or that the account configuration does not reflect the customer’s VAT status.

How does the reverse charge apply to Stripe fees?

Where Stripe does not charge VAT, UK VAT-registered businesses will generally need to apply the reverse charge to Stripe fees that are subject to VAT.

In practice, this involves:

• Calculating VAT on the Stripe fee at the UK standard rate where applicable
• Declaring that VAT as output tax
• Reclaiming the same amount as input tax, subject to normal recovery rules

For standard Stripe processing fees, reverse charge VAT will generally be reported in Box 1 (output tax) and Box 4 (input tax, where recoverable), with the net value reflected in Box 6 and/or Box 7 depending on the VAT scheme and accounting software configuration used.

Where a business is partially exempt, only part of the reverse charge VAT may be recoverable, which can turn Stripe fees into a real VAT cost.

Some Stripe charges, such as certain dispute-related services, may fall outside the reverse charge or be VAT-exempt depending on their nature. Correct classification based on the underlying service is important to ensure VAT is neither over- nor under-reported.

Should Stripe fees reduce revenue?

No. Where a UK ecommerce business is acting as principal, Stripe fees should not reduce reported revenue under UK accounting standards.

Revenue is recorded at the gross amount paid by the customer. Stripe fees are treated separately as operating expenses. This treatment is required under FRS 102 and aligns with HMRC’s definition of turnover.

Recording only net payouts as revenue:

• Understates turnover
• Distorts VAT registration threshold monitoring
• Weakens reconciliation and audit trails
• Creates common HMRC enquiry questions

The correct structure is:

• Gross sales recorded as revenue
• Stripe fees recorded in a separate expense account
• Bank payouts reconciled through a clearing or control account

This mirrors the treatment used for Amazon settlements, where sellers also receive net payouts but generally record gross sales where they are acting as principal.

How do I reconcile Stripe in Xero?

Reconciling Stripe in Xero typically involves separating Stripe activity from bank movements and using a clearing account.

A common monthly workflow includes:

1. Downloading Stripe balance summaries, payout reports, and transaction-level exports
2. Recording customer payments as gross revenue posted to a Stripe clearing account
3. Recording Stripe fees separately as expenses, including reverse charge VAT where applicable
4. Matching Stripe payouts to bank deposits
5. Reconciling the remaining Stripe balance to pending or reserved amounts shown in Stripe

At month end, the balance on the Stripe clearing account should align with Stripe’s reported balance. Any differences should be explainable by timing, such as funds captured but not yet paid out.

This approach creates a clear audit trail and allows Stripe balances, revenue, fees, and bank deposits to reconcile logically.

Do Stripe sales count toward the VAT registration threshold?

Yes. Stripe-processed sales count toward the UK VAT registration threshold at their gross value, not the net amount received in the bank.

The VAT threshold is based on taxable turnover, which reflects the value of supplies made to customers before deducting expenses such as Stripe fees.

For example, if a seller processes £92,000 of customer payments through Stripe over a rolling 12-month period and receives £89,000 after fees, the VAT threshold has still been exceeded. VAT registration is required even though the bank receipts are lower.

Monitoring the threshold using net payouts is a common cause of late VAT registration and backdated VAT liabilities.
For a detailed explanation of when VAT registration becomes compulsory for Amazon and multi-channel sellers (including Stripe/Shopify sales), see VAT Registration for Amazon Sellers – Do You Need It?.

How does HMRC verify Stripe turnover?

In practice, HMRC commonly verifies Stripe turnover using platform and processor data rather than relying on bank statements alone.

During an enquiry, HMRC may:

• Compare declared turnover to third-party data received from payment processors
• Request Stripe balance summaries, transaction-level exports, or payout reports
• Ask for reconciliations showing how Stripe data ties back to the accounting records and bank statements

Strong supporting evidence includes:

• Stripe balance and transaction reports
• Clear reconciliations between Stripe, the general ledger, and the bank
• Consistent treatment of revenue, fees, refunds, and chargebacks

Bank statements alone are rarely sufficient, as they show only net cash movements and do not evidence gross turnover or fee treatment.

11. Action Step: Download the Stripe Reconciliation Checklist

This final step focuses on turning Stripe accounting from a recurring source of uncertainty into a documented, repeatable process. By this point in the guide, the mechanics of Stripe reporting, VAT treatment, and reconciliation should be clear. What many sellers struggle with in practice is not understanding the rules, but applying them consistently each month as volumes grow and platforms multiply.

That is where a structured reconciliation checklist becomes a practical control rather than an administrative burden.

When you need a structured Stripe reconciliation

Many UK ecommerce sellers begin with informal checks, typically comparing Stripe payouts to bank deposits and assuming the difference represents fees. That approach can work at very low volumes, but it becomes unreliable as transaction counts increase or additional platforms are introduced.

There are several indicators that a more formal Stripe reconciliation process is needed.

One of the earliest signs is balance drift. Where the Stripe balance, including available, pending, or reserved funds, does not agree to the clearing account and differences roll forward month after month, the accounting records are no longer self-correcting. What start as timing differences can become permanent unexplained balances. In HMRC reviews, this is commonly viewed as a record-keeping weakness rather than a timing issue.

Refunds and chargebacks are another trigger. Once refunds span accounting periods, or chargebacks are deducted weeks after the original sale, informal tracking quickly breaks down. Without transaction-level matching to original Stripe charge IDs, it becomes difficult to evidence which sales were reversed and when VAT adjustments should be made.

Multi-currency sales add further pressure. As soon as Stripe processes non-GBP transactions, exchange rates and conversion timing introduce gains or losses that do not appear clearly in bank deposits. These differences should be identified and documented so that profit and VAT calculations can be supported and explained if reviewed.

Using Stripe alongside Amazon increases complexity again. Amazon operates settlement-based accounting with defined payout cycles, while Stripe uses transaction-level processing with rolling payouts. When both platforms feed into the same bank account, reconciling each platform independently is often the only way to maintain a clear audit trail.

Finally, growth itself is a trigger. As gross sales approach the £90,000 VAT registration threshold, which HMRC assesses based on gross taxable turnover in most standard ecommerce cases, relying on net Stripe deposits becomes increasingly risky. A structured reconciliation helps ensure gross sales are tracked accurately across rolling 12-month periods.

At any of these points, a checklist-based reconciliation moves from being helpful to being necessary.

How the checklist fits into the month-end close

Stripe reconciliation should not be treated as a standalone task. It needs to be embedded into the month-end close in the correct sequence so that VAT returns, management accounts, and year-end figures all rely on the same verified data.

In practice, Stripe reconciliation is best completed before VAT checks and before the final bank reconciliation is signed off.

A typical month-end flow for a UK Amazon or multi-channel seller looks like this.

First, Stripe reports are downloaded for the period. This includes balance summaries, transaction-level exports, payout reports, and fee breakdowns. These reports form the primary evidence for turnover, refunds, fees, and pending balances.

Next, the Stripe clearing account is reconciled to Stripe’s reported balance. This confirms that all sales, refunds, fees, and holds are reflected in the general ledger, with pending or reserved amounts clearly identified rather than hidden within unexplained differences.

Only once the Stripe figures reconcile should VAT checks be completed. At this stage, output VAT on sales and refunds, reverse-charge VAT on Stripe fees, and relevant VAT return values can be reviewed against Stripe’s source reports.

Where the business also sells through Amazon, Amazon settlement reconciliation should be completed in parallel using separate clearing accounts. Once each platform reconciles independently, the final bank reconciliation becomes straightforward, with deposits matched to already-validated ledger balances.

This sequencing matters. Reconciling the bank first, or preparing VAT returns before Stripe has been reconciled, often masks errors rather than resolving them.

The checklist is designed to enforce this order consistently each month, regardless of who performs the bookkeeping.

Download the Stripe reconciliation checklist

The Stripe reconciliation checklist converts the principles in this guide into a repeatable monthly control process.

It is designed for UK ecommerce businesses using Stripe, either on its own or alongside Amazon, and aligns with common workflows in Xero and QuickBooks.

The checklist covers:

• Reconciling gross Stripe sales to ledger revenue
• Matching refunds and chargebacks to original transactions
• Separating and validating Stripe fees, including reverse-charge VAT where applicable
• Identifying pending and reserved balances at period end
• Reviewing VAT figures before submission
• Documenting variances and resolutions for audit and enquiry purposes

Used consistently, the checklist helps demonstrate control, consistency, and reasonable care. It does not remove all risk, and it does not replace professional judgement or entity-specific advice, but it significantly improves the quality of records and the ease with which questions can be answered.

For a wider month-end process that also covers Amazon settlements, see Amazon Seller Bookkeeping Checklist (Free Template).

For UK ecommerce sellers using Stripe, this approach turns compliance from a reactive exercise into a routine part of running the business.

For a complete overview of how Stripe, Amazon, VAT, and bookkeeping fit together in a UK ecommerce business, see Amazon Seller Accounting – Complete Guide.