AI-Assisted Bookkeeping: What Online Merchants Should Check

November 2026

AI-assisted features are becoming more visible in accounting software and related services. For an online merchant, they may promise help with tasks such as categorising transactions or finding unusual entries. But an ecommerce connection that transfers information is not necessarily using AI, and an AI suggestion is not necessarily an approved accounting decision. Understanding that difference can help merchants and accountants decide where these tools fit—and where a person should remain involved.

AI suggestions are different from fixed rules

Many bookkeeping tasks can already be automated without AI. A fixed rule might say that transactions from a particular supplier should be assigned to a particular expense account. The rule follows the condition it was given; it does not need to interpret the transaction each time.

An AI-assisted feature may instead use available information to suggest a category, identify a possible duplicate or draw attention to an unusual transaction. What it can actually do depends on the product and its settings. Some features only offer suggestions, while others may be able to make changes automatically if the user permits it.

The distinction matters because a plausible suggestion can still be wrong. A description may be incomplete, a supplier may sell several types of product, or a transaction may need treatment that depends on information outside the software. An unusual entry is not automatically an error, either: it might reflect a legitimate one-off purchase or a seasonal change in sales.

Ask the provider which tasks use AI, what information the feature considers and whether suggestions are applied automatically. Also check whether users can see why a suggestion was made. Explanations may not be available for every feature, so the underlying evidence may still need to be checked separately.

Keep people responsible for the decisions

Before enabling a feature, agree with your accountant who will review its output and who can approve changes. For example, a merchant might review suggested categories during the week, while the accountant checks exceptions and significant adjustments at month-end. The right division of work depends on the business and the service the accountant provides.

Pay particular attention to decisions that affect tax, asset purchases or the treatment of owner transactions. An automated suggestion may not have the context needed to make those decisions correctly. Where the treatment is uncertain, retain the relevant invoice or other evidence and ask an appropriately qualified adviser.

It is also worth checking how corrections work. If a user changes an AI suggestion, does the software record who made the change? Can the original entry and its supporting information still be found? A clear record helps an accountant understand what happened later, especially if staff change or a question arises after the accounts have been prepared.

Do not assume that correcting one suggestion will prevent the same mistake in future. Some products may learn from corrections; others may not, or may use them in ways that are not obvious to the user. Check the documentation and continue reviewing repeat cases.

Check data access, cost and everyday usefulness

AI features can introduce additional questions about business data. Before turning one on, find out what information it can access, whether information is sent to another provider, how long it is retained and whether it may be used to improve the service. The answers will vary. Consider customer and supplier information as well as financial records, and check the terms against your business’s privacy obligations.

Limit access to people who need it. If the feature can alter records rather than merely suggest changes, confirm who is authorised to enable that setting. Also ask whether there are extra charges, usage limits or a separate subscription. A feature included in a trial may not be included in the plan you intend to keep.

A small test is more useful than assuming the feature will save time. Choose a manageable set of transactions and compare the suggestions with the decisions a knowledgeable reviewer would make. Record how often suggestions are useful, how often they need correction and how long review takes. Include ordinary transactions and a few less straightforward examples.

After the test, decide whether to continue with suggestions only, permit any automatic actions or leave the feature switched off. Revisit that decision if the product or your business changes. Time saved on initial entry is valuable only if the resulting records can still be reviewed and corrected without excessive effort.

Checklist

• Confirm which features use AI and whether they suggest or automatically make changes.
• Agree who reviews suggestions and who approves significant or uncertain entries.
• Check how corrections and the history of changes are recorded.
• Review data access, retention, provider terms and any additional charges.
• Test a small sample, including exceptions, before expanding use.
• Review repeat mistakes and reconsider settings when circumstances change.

When Platform Changes Affect Your Accounting Connection

October 2026

An ecommerce-to-accounting connection depends on more than its initial setup. Shopify, BigCommerce, Wix and accounting platforms provide interfaces through which integration services exchange information. When a platform changes those interfaces or its rules for applications, the service maintaining your connection may need to adapt.

A concrete example is Shopify’s published change in direction for its Admin API. This matters to merchants and accountants because an apparently technical change can create practical questions about maintenance, permissions and continuity. The useful response is not to follow every developer announcement, but to establish who maintains your connection and how changes will be handled.

A platform change is not automatically a replacement deadline

Shopify designated its REST Admin API as legacy on 1 October 2024. It also set a requirement that new public apps, from 1 April 2025, be built exclusively with the GraphQL Admin API. These are different ways for applications to request and exchange information with Shopify. The distinction generally matters more to the integration provider than to the person preparing the accounts.

These dates illustrate a shift towards a platform’s preferred connection method. They do not, by themselves, establish that every existing accounting integration stopped working on either date. In particular, a requirement for new public apps should not be read as a universal shutdown date for existing connections.

Shopify documents this policy in its REST Admin API reference. The position of an individual integration depends on how it connects, which platform features it uses and the provider’s maintenance arrangements. The implications for your particular service cannot be determined from the platform announcement alone.

Nor should merchants assume that Shopify’s policy applies to BigCommerce, Wix, QuickBooks Online or Xero. Each platform has its own rules. The broader lesson is that the connection method behind an integration has a lifecycle, even when the merchant-facing workflow appears unchanged.

For a merchant, the first question is therefore simple: does the provider support the platform’s applicable requirements, and is any action needed from us? A clear answer is more useful than a general statement that an integration uses newer technology.

Treat maintenance and access as operating responsibilities

A subscription to an integration service should be considered alongside the responsibility for keeping that service connected. Ask what routine platform updates the provider handles, how customers are notified of required action, and whether a significant migration could involve additional charges. Do not assume that every maintenance task is included; check the service terms or obtain clarification.

Ownership also matters. A connection may have been authorised by a founder, an employee, an accountant or an outside implementer. If that person leaves or loses access, the business needs another authorised person who can manage the connection. Record the responsible role, the support contact and where account administration is handled, without putting passwords or secret credentials in a shared document.

A provider may ask you to reconnect an application or approve different permissions during an update. That request is not automatically a warning sign, but it deserves scrutiny. Confirm it through the provider’s usual support channel, review the access requested, and ask why any additional permission is necessary.

Use the platform’s own authorisation process where available rather than sharing a personal password. Merchants and accountants should also agree who can approve changes. The person authorised to manage the store may be different from the person authorised to connect the accounting organisation.

These controls are particularly useful for businesses with staff turnover or external bookkeeping support. They make routine maintenance less dependent on one person remembering how the original setup was completed.

Prepare for changes without disrupting bookkeeping

If your provider says a connection needs updating, ask for a plain-English description of what will change. Will the work happen in the background, or must someone approve access? Is an interruption expected? Will historical information remain available? Which checks should the merchant and accountant perform afterwards?

Agree a suitable window for any customer action. Avoid scheduling it immediately before a reporting deadline if there is a reasonable alternative. Keep a record of the last successful import and any transactions awaiting transfer, so that both parties can identify the starting point after the change.

Do not disconnect the old connection, create a replacement or manually re-enter missing transactions without understanding the provider’s instructions. Depending on the service, those actions could create duplicate entries or make recovery harder. If imports pause, agree who will monitor the backlog and when manual processing becomes necessary.

Afterwards, confirm that access works and that expected transactions are arriving. An updated connection does not necessarily mean your accounting treatment has changed. However, if the provider identifies changed behaviour, the accountant should review that specific effect rather than assuming everything is identical.

A short maintenance plan turns platform changes into a manageable operational task. Use this checklist:

• Identify who owns the integration and can authorise changes on both platforms.
• Ask the provider whether the announced policy affects your specific connection.
• Confirm maintenance coverage, notification arrangements and possible charges.
• Review reconnection requests and any additional access permissions.
• Record the last successful import before planned work.
• Agree post-change checks and a process for handling interrupted imports without duplication.

Integration trends: why ecommerce accounting is getting more complex

September 2026

If you sell online, your store and your accounting system need to agree on the basics: what you sold, what you collected, what you refunded, and what it all cost you in fees and taxes. A noticeable trend over the last couple of years is that this “agreement” has become harder to maintain with simple, one-size-fits-all setups. The practical reason is straightforward: more payment options, more marketplaces, more cross-border sales rules, and more detailed reporting expectations have increased the number of moving parts between ecommerce and accounting.

This post focuses on what has changed in practice, and what small-to-medium merchants and their accountants can do to reduce errors and month-end surprises—without needing to follow daily product updates from every platform.

Trend 1: Payments are more fragmented, and deposits rarely match sales

Many merchants now accept a mix of card payments, digital wallets, “buy now, pay later” providers, local payment methods, and sometimes multiple payment processors. Even when everything is offered through a single checkout, the money may still be settled in batches, across different schedules, and with different fee structures.

Practical implication: the amount deposited to the bank for a day (or week) often won’t equal the gross sales in the store for that same period. That’s not new, but it’s becoming more common for the mismatch to be driven by several factors at once:

• Processing fees and rolling reserves: fees may be withheld per transaction or per payout; reserves may delay part of the cash.
• Refund timing differences: refunds can be issued today but netted against a later payout.
• Chargebacks and disputes: money may be removed after the original sale date, sometimes with additional fees.
• Multi-currency settlement: the store may report one currency while the payout arrives in another, with FX conversion effects.

For accounting, this pushes many businesses away from “post sales directly to the bank” approaches. Instead, accountants often prefer a clearing account (sometimes called an “undeposited funds” or “payment processor clearing” account) so that sales, refunds, fees, and payouts can be reconciled systematically.

What to do: agree up front on the unit of reconciliation. Some teams reconcile to payouts (e.g., one journal per payout), others reconcile daily. Either can work, but mixing methods mid-year can create confusion. Also decide whether fees will be posted as a single line per payout or broken out (useful for analysis, but more work).

Trend 2: Tax and compliance reporting expectations are rising

Tax calculation and reporting for online sales has been evolving across many regions. The details vary by country and by where your customers are, and they can change over time. While it’s difficult to summarise every rule, there is a consistent direction: more jurisdictions expect clearer audit trails for what tax was charged (or why it wasn’t), and platforms increasingly provide more tax-related fields and reports.

Practical implication: the accounting system needs data that supports your tax position, not just a total sales number. That often means paying closer attention to:

• Tax-inclusive vs tax-exclusive pricing: mismatches here can distort revenue and tax liability.
• Jurisdiction-based rates: the rate can depend on customer location, product type, and thresholds.
• Marketplace vs direct sales: in some arrangements, marketplaces may collect and remit certain taxes, changing what you should record as tax payable.
• Shipping, discounts, and gift cards: these can affect taxable amounts in different ways depending on local rules.

This trend affects integrations because merchants and accountants increasingly need control over how orders map into the chart of accounts and tax codes. A simple “all sales to one income account” setup may still be fine for some businesses, but others need separate lines for product sales, shipping income, discounts, tax collected, and fees—especially when cross-border sales grow.

Where uncertainty exists: tax treatments can be fact-specific. Two businesses using the same ecommerce platform may need different accounting mappings depending on their registrations, customer locations, and how they fulfil orders. If you’re unsure, document your assumptions and confirm them with a qualified adviser.

Trend 3: More sales channels means more adjustments and “edge cases”

Even smaller merchants now commonly sell through more than one channel: their own site, social commerce, wholesale invoicing, and sometimes one or more marketplaces. Each channel can have different definitions for key events like “order created,” “payment captured,” “fulfilled,” “returned,” or “cancelled.”

Practical implication: the number of exceptions increases. Typical examples include:

• Partial refunds and exchanges: the store may treat an exchange as a return plus a new sale, while accounting may prefer a net view.
• Bundles and kits: ecommerce may sell a bundle SKU, but accounting/stock systems may need component-level tracking.
• Backorders and split shipments: revenue recognition timing may differ from fulfilment timing (your accountant may have a preferred policy).
• Gift cards/store credit: often a liability at sale, then revenue later on redemption; some platforms record this in multiple ways.
• Manual adjustments: edits to orders after the fact can cause integration reruns or duplicated postings if processes aren’t clear.

These edge cases are where integration setups tend to drift over time. A mapping that was accurate when you sold only domestic, card-only orders can become unreliable once you add subscriptions, multi-currency pricing, or a second warehouse.

What to do: set a cadence for reviewing your integration rules—quarterly is common for growing businesses. Ask: did we add a new payment method, a new sales channel, a new tax registration, or new shipping terms? If yes, confirm that the accounting mapping still reflects reality. Keep a short “integration change log” (even a shared document) so that when numbers move, you can trace why.

• Choose a reconciliation approach: reconcile by payout or by day, and keep it consistent.
• Use a clearing account if payouts don’t match sales: ensure fees, refunds, and chargebacks have a clear home.
• Confirm tax settings: document whether prices are tax-inclusive and how shipping/discounts are treated.
• Review multi-currency handling: decide where FX differences should be recorded in the accounts.
• List your edge cases: partial refunds, gift cards, bundles, and split shipments—agree on the accounting treatment.
• Schedule a quarterly integration review: especially after adding payment methods, channels, or new jurisdictions.
• Keep an audit trail: save key reports (sales, refunds, fees, payouts) so month-end can be explained quickly.

Further reading: CarryTheOne publishes integration guidance and practical examples at https://www.carrytheone.co.uk.

Accounting Integrations Are Shifting Toward Cleaner Data Flows

August 2026

For online merchants, the link between your ecommerce platform and your accounting system is no longer just a “nice to have”. It shapes how quickly you can close the books, how confidently you can report tax, and how much manual work your team (or accountant) has to do each week. Over the past couple of years, a clear trend has emerged: integrations are increasingly built around cleaner, more standardised data and better auditability, rather than simply pushing totals into accounting software as fast as possible.

This post explains what’s changing in practical terms, why it matters even if you don’t follow product updates, and what small-to-medium merchants can do to reduce errors and end-of-month surprises.

Trend: Moving from “summary posting” to structured, auditable transactions

Historically, many ecommerce-to-accounting setups focused on posting a daily (or weekly) sales summary: one journal entry for sales, one for refunds, one for fees, and so on. That approach can still work, but more merchants now want accounting records that are easier to trace back to what happened in the store and payment processor.

In practice, the shift looks like this:

1) Better breakdowns of what makes up “sales”
Online sales are rarely a single number. They include product revenue, shipping income, discounts, gift cards, tips (in some industries), and sales tax/VAT collected. Many integrations increasingly try to map these components into separate accounts or lines, so your P&L and balance sheet are easier to interpret.

2) More attention to timing differences
Ecommerce platforms record orders when the customer checks out. Accounting systems usually care about when payment is captured, when goods are shipped (in some setups), and when funds settle in the bank. Integrations are increasingly designed to cope with this reality—so that “sales” in the books can be reconciled to deposits and fees without excessive manual adjustment.

3) Stronger audit trail expectations
Accountants often need to answer “why is this number different?” Integrations that preserve references (order IDs, payout IDs, fee categories) make it easier to trace figures during a VAT return, year-end review, or a cash-flow discussion.

Practical implication: If your business has grown, the “one daily total” approach can start to break down—especially once you introduce multiple payment methods, partial refunds, subscriptions, or marketplaces. Moving to a more structured feed can reduce the time spent explaining variances later, but it may require more deliberate setup (accounts, tax codes, and payout mapping).

Trend: Payout-based reconciliation is becoming the operational “centre”

Another noticeable shift is that many finance teams now organise ecommerce bookkeeping around payouts (the deposits you actually receive) rather than around orders alone. This is partly driven by how payment processors and ecommerce platforms present data: payouts group many underlying transactions and apply fees, chargebacks, and adjustments before funds hit the bank.

For merchants, this payout-first mindset affects day-to-day processes:

Reconciling becomes more predictable
When accounting entries are aligned to payout periods, it’s often easier to match them to bank deposits. This can reduce “mystery differences” caused by processor timing, currency conversion, or rolling reserves.

Fees and disputes get handled more explicitly
Payment processing fees, chargebacks, and dispute losses can be posted as separate categories rather than being buried inside a net deposit figure. That improves margin analysis and helps accountants assess the true cost of each payment method.

Refund timing becomes clearer
Refunds may occur days after the original sale, and some processors net refunds against future payouts. A payout-based approach can make these movements visible and easier to explain, even when they cross month-end.

Where uncertainty exists: Not every platform or processor exposes the same level of detail, and not every merchant needs payout-level bookkeeping. Some businesses still prefer order-level posting (for example, where inventory accounting or detailed customer reporting is central). The “best” approach depends on reporting needs, transaction volume, and how your accountant wants to evidence balances.

Trend: More complexity from multi-channel selling and tax rules

Small-to-medium merchants increasingly sell through a mix of channels: their own store, social commerce, marketplaces, wholesale invoicing, and sometimes multiple storefronts by region. Accounting needs to keep up, and integrations have had to become more flexible as a result.

Common pressure points include:

Multiple tax treatments in the same business
VAT/GST rules can differ across product types and destinations. Even within one platform, you may have zero-rated items, reduced rates, or mixed supplies. An integration that posts a single blended tax figure can make returns harder to verify. More detailed mapping helps, but only if your tax setup in the store is correct.

Currency and settlement differences
Selling internationally can create gaps between the order currency, settlement currency, and your base accounting currency. Exchange rates used by processors may differ from your accounting system’s rates. Good integrations try to keep the trail clear (what the customer paid, what was converted, what was deposited), but some differences may still need manual review—especially at period end.

Separate revenue streams need separate reporting
If you want to know whether a channel is profitable, you need sales, refunds, shipping income, and fees attributable to that channel. This is less about “more data” and more about “data that lands in the right place” in the chart of accounts.

Practical implication: As your channel mix grows, the accounting impact grows faster than many merchants expect. A quick health check of mappings and reconciliation routines can prevent the situation where the books are technically “up to date” but management reports are misleading.

For merchants evaluating their setup (or accountants inheriting a client’s existing workflow), it can help to look for an integration approach that supports clear mappings, consistent references, and reconciliation around real-world cash movements. CarryTheOne’s overview of ecommerce-to-accounting connections is available at carrytheone.co.uk.

Concluding checklist

• Confirm your reconciliation anchor: are you reconciling to orders, to payouts, or to bank deposits—and does everyone involved agree?
• Review the sales breakdown: ensure product revenue, shipping, discounts, gift cards, and tax are not unintentionally blended.
• Check refund and dispute handling: verify how refunds, chargebacks, and processor adjustments are posted and how they affect month-end figures.
• Map fees deliberately: separate key fee types where possible so margins and payment-method costs are visible.
• Validate tax setup in the store: an integration can only post accurate tax if the platform’s tax configuration is correct.
• Look for traceable references: payout IDs, order IDs, and clear memo fields make audits and queries faster.
• Do a month-end dry run: test how the integration behaves across month-end (timing differences, currency, refunds) before it becomes urgent.

Ecommerce Accounting Integrations: Moving Toward Cleaner Data

July 2026

If you run an online store, your accounting is only as reliable as the data that reaches it. Over the past couple of years, a clear trend has emerged across ecommerce-to-accounting integrations: merchants and accountants are paying less attention to “getting data across at any cost” and more attention to data quality—especially how payouts, fees, taxes, and refunds are represented in the books.

This matters because ecommerce has become more complex: multiple payment methods, faster shipping expectations, more returns, and expanding tax rules. Integrations are increasingly expected to handle these realities in a consistent way so that month-end close is predictable and audit trails are clearer.

1) Payout-based reconciliation is becoming the default expectation

Many merchants used to push every order line into accounting and assume the bank deposit would “roughly match” once fees were considered. In practice, that approach often creates messy reconciliation: the deposit rarely equals the sum of orders because gateways, marketplaces, and “buy now, pay later” providers deduct fees, hold reserves, and batch payments.

The growing expectation is that integrations should help you reconcile accounting entries to actual payouts—the amounts that land in your bank account—rather than only to order totals. Even when the integration still posts sales per order, users increasingly want reporting that makes it easy to tie sales activity to the payout amount: gross sales, refunds, shipping, taxes collected, payment processing fees, and net settlement.

Practical implications:

For merchants, payout-aware posting usually makes bank reconciliation faster and reduces the number of manual journal entries needed to “true up” fees and timing differences. For accountants, it can improve the audit trail: each bank deposit can be matched to a settlement period, with supporting detail available if you need to drill down.

What to watch for: payout timing differences. Some providers settle on schedules that don’t match your order dates, and refunds can be deducted from later payouts. Even with a good integration, you may need to agree on a policy for how to handle timing (for example, posting sales by order date but tracking settlements separately, or posting summaries by payout date). There is no single right answer; it depends on reporting needs and how management reviews performance.

2) More emphasis on accurate mapping for taxes, discounts, and fees

A second trend is that integrations are being judged less by how many fields they can sync and more by whether key accounting categories are mapped consistently. This is partly because tax rules and reporting expectations have become more demanding, and partly because finance teams want cleaner management reporting.

Common problem areas include:

Sales tax / VAT: Whether tax is posted to a liability account correctly, and whether tax-inclusive pricing is handled properly. In some setups, tax can be overstated or understated if discounts and shipping are treated inconsistently.

Discounts and promotions: Discounts may be represented as negative income, as a contra-revenue account, or distributed across line items. Each method can be valid, but mixing methods month to month makes reporting unreliable.

Shipping income and shipping costs: Merchants often want shipping charged to customers separated from product sales, while carrier costs go to an expense or cost-of-sales account. When these are blended together, gross margin analysis becomes harder.

Payment processing fees: Fees can be posted per transaction, per payout, or as a monthly statement total. The “best” approach depends on materiality and how much detail you need, but the mapping must be consistent.

Practical implications:

If you sell across multiple channels or use multiple payment methods, it’s worth documenting your mapping decisions in plain English and sharing them with whoever maintains the integration. A small decision (like whether discounts reduce revenue or are tracked separately) can significantly change reported sales and margin.

Uncertainty to note: tax handling varies by platform, region, and configuration. Even well-known ecommerce and accounting tools can behave differently depending on settings (for example, whether prices include tax, whether taxes apply to shipping, and how returns are processed). It’s sensible to validate the first month of postings against known totals before assuming the mapping is correct.

3) Merchants are standardising on “summarised” posting to reduce noise

As order volumes grow, posting every transaction to the accounting platform can create performance and review problems: large ledgers, difficult reconciliation, and time-consuming searches. Many merchants and accountants are shifting toward summarised postings—for example, daily or payout-period summaries—while keeping order-level detail in the ecommerce platform and in reports exported for analysis.

This isn’t about losing detail; it’s about keeping the general ledger readable. For many small-to-medium businesses, the accounting system is primarily used for statutory reporting, tax filings, and management accounts. In that context, thousands of near-identical entries may not add value.

Practical implications:

Summaries can make month-end close faster, but they require agreement on how exceptions are handled. For example:

Chargebacks and disputes: Do you post them as they occur, or when they are settled?

Refund timing: If a refund happens days after the original sale, do you adjust the original day’s summary or post the refund on the day it occurs?

Multi-currency sales: Summaries need a clear exchange-rate policy. Accounting platforms handle currency conversion, but your integration approach determines where gains/losses appear.

Accountants often prefer a repeatable method they can test: a summary that ties to a settlement report, plus a clear way to trace back to the underlying orders when needed.

For merchants evaluating integrations, it can help to ask for a sample posting set (even screenshots) showing how a typical payout, a refund, and a partial refund appear in the ledger. This is usually more informative than feature lists.

Checklist: what to review in your current setup

• Can you reconcile each bank deposit to a specific payout or settlement report without manual “plug” entries?
• Are payment processing fees recorded consistently (and to the accounts your accountant expects)?
• Do taxes (VAT/sales tax) post to the correct liability accounts, and do totals match platform reports for the same period?
• Are discounts and gift cards treated consistently, with a clear policy for reporting revenue?
• Are refunds and partial refunds handled in a way that’s easy to understand at month end?
• If you use summaries, do you have a repeatable drill-down path from ledger entries to orders and payout details?
• For multi-currency selling, is your exchange-rate approach documented and consistent across platforms?
• After any platform or app changes, do you re-check the first week or month of postings against expected totals?

Further reading: an overview of ecommerce-to-accounting integration options is available at https://www.carrytheone.co.uk.

Ecommerce accounting integrations: the shift toward cleaner data

June 2026

For many small-to-medium online merchants, ecommerce-to-accounting integration used to be a one-off setup: connect your store, map a few accounts, and let the sync run. In the last couple of years, the practical reality has changed. More businesses now sell across multiple channels, use more apps (subscriptions, bundles, returns portals, marketplaces), and operate in more than one tax jurisdiction. That has increased the consequences of small data differences between platforms.

A clear trend in the integration landscape is a stronger focus on data quality and auditability: integrations are being judged less on “does it sync?” and more on “does the data reconcile, stay consistent over time, and stand up to review?” This matters even if you don’t follow product news, because it affects how you should structure your chart of accounts, how you manage tax settings, and what you should check each month.

1) Reconcilable numbers are becoming the baseline expectation

Integrations increasingly need to produce accounting outputs that reconcile to real-world cash movement and to platform reports. The reason is simple: merchants and accountants are spending more time investigating differences between storefront sales reports, payment processor payouts, and the accounting ledger.

In practice, reconciliation pressure tends to show up in three places:

Payment timing and settlement. Online stores often record sales at the time of order, while funds arrive later (and sometimes in batches) from payment processors. As merchants add more payment methods (cards, wallets, BNPL, local methods), settlement patterns can get more complex. A “sales equals bank deposits” mindset often breaks down; instead, teams need a consistent approach to recognising sales, fees, refunds, and settlements so that clearing accounts reconcile.

Returns, exchanges, and adjustments. Returns flows vary by platform and app: some create new orders, some modify existing orders, and some issue multiple refunds over time. Accounting systems generally need a stable method for representing these events so that revenue, tax, and inventory movement (where applicable) aren’t overstated. As return volumes rise in many categories, even small handling differences can become material over a quarter.

Fees and “other” charges. Shipping, tips, gift wrap, duties, and platform fees can be recorded in different places. The more add-ons a merchant uses, the more likely these amounts will be split across line items, discounts, or separate transactions. Integrations that produce usable accounting records usually make these categories explicit and consistent.

Practical implication: merchants and accountants should agree up front on what “reconciles” means for the business (for example: bank deposits to clearing account movements; gross sales to platform sales reports; tax to tax reports). Once defined, choose an integration configuration that supports those checks, rather than relying on the default mapping.

2) Tax complexity is pushing integrations toward clearer tax handling

Tax rules have not become simpler, and ecommerce has continued to expand across borders. Even without following daily regulatory updates, many merchants feel the operational impact: more locations, more tax rates, and more edge cases (discounts, shipping taxability, VAT-inclusive pricing, partial refunds).

What’s changing in the integration landscape is the expectation that tax treatment is transparent in the accounting output. Merchants and accountants often need to answer basic questions quickly:

• Was tax calculated by the ecommerce platform, a marketplace, or a tax app?
• Is the accounting system expected to re-calculate tax, or only record it?
• Are prices tax-inclusive or exclusive, and is that consistent across channels?
• Do refunds reverse tax correctly and in the correct period?

There isn’t a single correct approach for every business. Some teams prefer to post tax as reported by the storefront or marketplace to reduce differences between operational reports and accounting. Others prefer to let the accounting platform calculate tax based on mapped tax codes. The right choice depends on the jurisdictions involved, the reliability of source data, and how returns and adjustments are handled.

Practical implication: treat tax as a design decision, not an afterthought. Document the intended flow (who calculates tax, where it is recorded, and how it is reported). If you operate in multiple regions, run a short “sample month” test that includes refunds and shipping, and compare platform tax reports to the accounting ledger before going live.

3) Multi-channel selling is increasing the need for consistent categorisation

Many SMEs now sell through a mix of direct-to-consumer storefronts, marketplaces, social channels, and wholesale or invoiced orders. As a result, the accounting view needs to answer management questions that a single-channel setup could ignore: performance by channel, margin by product group, or the cost impact of a specific payment method.

The integration trend here is a move away from a single generic “Sales” posting toward more structured categorisation. Common examples include:

• Channel-level income accounts (e.g., Shopify sales vs marketplace sales) to support profitability analysis and easier troubleshooting.
• Separate tracking for discounts so that gross sales and promotional impact are visible without manual work.
• Shipping income and shipping costs recorded separately, which helps when shipping charges are collected from customers but carrier costs move differently.
• Payment processing fees captured consistently, enabling clearer net sales reporting.

This does not mean every business needs a complicated chart of accounts. Overly detailed categorisation can create its own maintenance burden. The goal is consistency: the same type of transaction should land in the same place every time, across channels and over time.

Practical implication: decide which dimensions matter for decision-making (channel, product category, region) and implement only those. If you already have an integration, check whether your current mappings still match how you operate today—especially if you added new sales channels or apps after the original setup.

Concluding checklist: what to review this month

• Define reconciliation targets: confirm which reports should match (store sales, payouts, bank deposits, tax reports) and at what level of detail.
• Review clearing accounts: ensure payment processor activity (sales, fees, refunds, chargebacks) can be tied to settlements and bank movements.
• Test refunds and partial refunds: check how revenue and tax are reversed and whether timing creates period-end differences you need to explain.
• Confirm tax responsibilities: document whether tax is calculated by the storefront/marketplace or the accounting platform, and make sure mappings reflect that decision.
• Check categorisation: validate that shipping, discounts, tips, duties, and fees are posted consistently and not buried in generic sales lines.
• Audit a sample set: pick 10–20 transactions across channels (including one return) and trace them from order to payout to ledger.
• Agree on change control: when you add a new app, channel, or payment method, include an accounting impact review before it goes live.

Further reading: a general overview of ecommerce-to-accounting sync options is available at CarryTheOne.

New CarryTheOne FreeAgent Connector for Ecommerce Accounting Automation

CarryTheOne is pleased to announce the addition of the popular SaaS accounting application FreeAgent to its integration platform for connecting with any of the supported shopping carts.

The new connector allows ecommerce sales activity to be imported automatically into FreeAgent, helping online retailers reduce repeated manual data entry while keeping accounting records aligned with store orders, refunds, payments and customer information.

What the FreeAgent connector does

The FreeAgent connector can import ecommerce orders into FreeAgent as invoices, and refunds or returns as credit notes. It can also create or match FreeAgent contacts automatically, helping keep customer records tidy as sales activity is imported.

For businesses dealing with VAT, different shopping-cart tax behaviours and payment totals, the connector includes VAT-aware line creation and rounding support. Where needed, CarryTheOne can create rounding adjustment lines so FreeAgent invoice totals match the totals from the ecommerce platform or payment data.

The connector also supports configurable mapping of invoice and credit-note lines to FreeAgent categories and nominal codes, giving businesses control over how sales, refunds, fees and other lines are represented in FreeAgent.

Payments, emails and workflow options

Depending on the shopping cart and configuration, CarryTheOne can optionally create invoice and credit-note payments in FreeAgent using bank transaction explanations. Payment-fee expense transactions can also be supported where the relevant payment and fee data is available.

The connector can optionally mark invoices and credit notes as sent or open, and can email documents through FreeAgent. Where FreeAgent default email templates are available, those can be used; otherwise, CarryTheOne-configured subject and body templates can provide a fallback.

Built to avoid duplicate accounting records

The connector includes duplicate invoice and reference handling, including automatic retry using suffixed references where needed. It also uses tracker-based idempotency so repeated service runs do not create duplicate accounting records.

Configuration options are available through the CarryTheOne Configuration Panel, including FreeAgent accounts, tax rates, categories, bank accounts, payment methods, document numbering and reference behaviour, email behaviour and payment creation.

Getting started

To try the new FreeAgent connector, sign up for CarryTheOne, select your shopping cart and FreeAgent, then follow the installation and configuration steps in your account.

You can choose a compatible FreeAgent connector from the FreeAgent landing page to see platform-specific details.