There is a moment that CPAs serving ecommerce clients know well. The engagement letter is signed, the previous firm's books appear intact, the integration tool is posting, the clearing account has a balance. Everything ties to something internally, yet underneath that surface coherence, the inevitable question arises: what has actually been verified from source here, has this simply been posted and brushed over, am I missing something?
For the better part of a decade, the US professional services infrastructure serving multi-channel ecommerce has operated on an implicit assumption: that platform settlement data is reliable, that integration tools transform it correctly and that a clearing account which closes, even approximately, represents a reconciliation. That assumption not only carries federal tax exposure, it carries professional liability. In restructuring cases, it means arriving at an appointment where the platform holds funds the estate is owed, and the standard asset-tracing procedures were never designed to find them. It carries silently, compounding under the surface of otherwise ordinary client files, until it does not.
That assumption covers a large and growing surface area. The US Census Bureau's Quarterly Retail E-Commerce Sales report for Q4 2025 records US retail ecommerce at $1.23 trillion for the full year, with the fourth quarter alone at $316.1 billion, up 5.3% year-on-year. Multi-channel selling is the norm: more than half of Walmart marketplace sellers also sell on Amazon. The surface area of the US economy that now moves through platform and payment-service-provider settlement infrastructure is the scale of a G20 national economy, governed by the mechanics of a handful of platforms. It passes through the hands of every CPA and forensic accountant who serves an ecommerce client. Verified from source in the ordinary course of professional services by essentially nobody.
What follows is the full account of that gap, where it sits, what it costs and why it has not been fully closed until now.
Four versions of reality
For every multi-channel ecommerce engagement, four distinct data sources coexist and do not reconcile by default.
The accounting software holds what was posted. The integration tool holds what was sent. The platform's own settlement reports hold what was calculated. The bank statement holds what actually arrived. None of them agree.
The disagreements are not errors to be corrected. They are structural features of how the settlement architecture works. Platforms report gross sales. Payment gateways report net settlements after fees, refunds, chargebacks, reserves, and holdbacks. Banks report consolidated deposits with no itemization. The accounting software posts whatever the integration tool produces, which is whatever the integration tool's transformation logic did to the platform's export. Each transformation is correct on its own terms and produces a figure appropriate for the purpose it serves.
None of them, individually, answers the question every serious professional on a multi-channel ecommerce engagement eventually needs to answer: what actually reached the bank, across every channel, over the period this engagement covers?
The integration tools do not answer it. They were not designed to. The platforms' own summary interfaces do not answer it; they are single-platform surfaces on a multi-platform question. The accounting software does not answer it; it holds what was posted, not what was verified. The bank statement does not answer it alone; it shows what arrived, not which platform sent it, under which settlement period, and whether the platform's own account of what it sent is correct.
When the business sells cross-border, the complexity compounds. A US seller trading into Canada, the UK, or the EU through Amazon or Shopify encounters a layered structure of currency conversions: the platform's own rate at settlement, the payment gateway's conversion with its own fee, and the bank's rate when the deposit arrives in the merchant's reporting currency. The composite spread is material and invisible from the ledger. It can only be reconstructed by pulling the platform's original transaction data and comparing against historical market rates for the relevant settlement dates. That reconstruction is not part of any standard bookkeeping workflow. The merchant absorbed the spread. Nobody documented it.
Answering the multi-channel question requires going back to the raw source: the SP-API settlement export (Amazon's programmatic settlement-data interface, as distinct from the summary reports visible in Seller Central), the PayPal transaction report, the Etsy deposits CSV, the Shopify Payments payout history, and the bank statement that every entry must ultimately reconcile to.
The 1099-K problem, and why it is not going away
The gross-versus-net confusion is not a bookkeeping error. It is a structural feature of how ecommerce platforms report and the IRS has put its position on the record.
IRS Fact Sheet 2025-08, issued on 23 October 2025, is explicit: Form 1099-K reports the total gross dollar amount of reportable payment transactions with no subtraction for processing fees, chargebacks, refunds or shipping costs. On a typical Amazon seller's account, those deductions can represent 30% to 50% of the gross figure. The same fact sheet confirmed that the reporting threshold has reverted to $20,000 and 200 transactions, where it stood before the American Rescue Plan Act temporarily lowered it to $600 in 2021. The $600 threshold was never implemented: the IRS delayed it three times before Congress repealed it outright in the One Big Beautiful Bill Act, signed into law on 4 July 2025. For the four years between announcement and repeal, merchants and their CPAs operated under a threshold that kept changing and was never enforced as stated.
In practice, a merchant operating above the threshold receives a 1099-K showing gross platform receipts. Their bank account received net platform settlements. The gap between the two is every fee Amazon deducted, every Shopify chargeback reversed, every PayPal reserve held, every return processed. That gap is not income. It is also not documented, identified, or separated in the bundled payout that reaches the bank. In the ordinary course of bookkeeping, that gap is carried forward without being reconciled against the underlying platform data that generated it.
A CPA firm filing a return that reconciles 1099-K gross to a number different from the client's books, without source documentation of how the two were bridged, is filing on a position they cannot demonstrate. The IRS's increasing deployment of third party data-matching under the 1099-K regime means that position is increasingly testable from the outside.
In March 2026, the South Carolina Supreme Court ruled that Amazon owed $12.5 million for a single quarter's third-party transactions, with $277.2 million of total exposure pending, finding that Amazon's control over third-party transactions was so significant that a sale could not occur on its platform without Amazon's own actions. The ruling establishes that marketplace-facilitator collection obligations existed under pre-2019 general "seller" statutes. For the settlement verification question, the finding confirms what practitioners already experience: Amazon exercises comprehensive control over the transaction, the fee structure, and the settlement mechanics. The data that documents what was deducted and what was paid sits inside that controlled environment. It does not arrive in the merchant's bank account in a form that explains itself.
The discrepancy runs in both directions
How large is the undocumented gap? It is not speculative, the Treasury Inspector General for Tax Administration has quantified it.
Between 2017 and 2020, the Treasury Inspector General for Tax Administration examined Form 1099-K discrepancies across the US ecommerce economy. The numbers were large. TIGTA Report 2021-30-002 (December 2020) identified 314,586 business taxpayers whose filed income did not match their 1099-K gross, covering $335.5 billion in reported payments. TIGTA estimated $5.7 billion in additional potential tax. An earlier report (2017-30-083) found 20,881 taxpayers with discrepancies over $10,000 that went entirely unaudited. A third (2019-30-016) documented a 237% growth in 1099-K discrepancy cases across nine gig-economy payers between 2012 and 2015.
TIGTA assumed every one of those discrepancies was income the seller owed and had not reported. The IRS then pursued the cases and discovered that assumption was wrong.
In its formal response appended to the 2021 report, the IRS disclosed that its Business Underreporter program pursued 3,456 Form 1099-K discrepancies covering $2.5 billion in TY 2017 payments and found actual underreporting in only 22% of cases, yielding $31 million in assessments. Its individual Automated Underreporter program pursued over 72,000 cases covering $31.6 billion and converted only 6% of proposed tax into actual assessment. De Lon Harris, then Commissioner of the Small Business/Self-Employed Division, stated that "proceeds reported on a Form 1099-K may not always be taxable." Between 78% and 94% of the discrepancies that TIGTA counted as underreported income turned out to be something else entirely.
The IRS's own conversion data encompasses multiple explanations for the non-conversion, including shared payment terminals, related-entity reporting, income reported on different return line items, and sellers who correctly reported net income against a gross-reporting form. The overpayment share within that 78–94% has never been measured in any published dataset. But the structural conditions that produce overpayment are documented independently. GAO-24-107028 (September 2024) acknowledged explicitly that "some taxpayers may inadvertently overreport their taxable income" because Form 1099-K reports gross payments that includes fees and commissions retained by the platform.
If 78–94% of those discrepancies were not tax owed to the IRS, how many of them were tax owed back to the seller? The reframe
That finding should concern every CPA serving ecommerce clients, because it raises the question nobody in the federal reporting chain has answered: if 78–94% of those discrepancies were not tax owed to the IRS, how many of them were tax owed back to the seller?
The mechanics make overpayment not just possible but predictable. A seller whose CPA filed on the 1099-K gross figure without reconstructing the fee deductions from the platform's settlement data overpaid tax on every dollar of platform fees, every chargeback, every reserve hold and every returned goods credit that was included in the gross, but was never income. The FTC's complaint against Amazon alleges that sellers pay close to 50% of their total revenues in platform fees. At that fee burden, some sellers who filed on gross without deducting fees overpaid on nearly half their reported revenue.
For the avoidance of any doubt, the IRS will not tell your client this has happened. Its Automated Underreporter program, governed by IRM 4.19.3, generates CP2000 notices when a taxpayer's reported income falls below the information return figure. There is no systematic flag for the opposite scenario: a taxpayer who reported more income than their net settlement supports. The matching infrastructure is directionally asymmetric. It is built to catch underpayment, it is structurally blind to overpayment. No statute, regulation, or IRM provision requires the IRS to notify a taxpayer that third party data suggests they overpaid.
The burden is on the business owner to file an amended return under IRC §6511, generally within three years from filing or two years from payment. For tax year 2022, filed by April 15, 2023, that window closed on April 15, 2026. Any TY 2022 overpayments from the period of maximum 1099-K threshold confusion, when the ARPA $600 rule had been announced but not implemented and the IRS was issuing interim guidance that changed year to year, are now permanently unrecoverable unless already claimed.
For a CPA serving ecommerce clients, the inescapable conclusion is: if you have not reconciled your ecommerce clients' transactions against the platform's own source data, you do not know which direction the discrepancy runs, neither does your client and the IRS will not inform either of you. Your clients may owe tax they have not paid, however it is highly likely that they may have in fact paid tax they do not owe, on a refund clock that is running down. A documented position is one you can file on, amend from, or defend. An undocumented one is a position you are carrying without knowing what it contains.
What a clearing account balance is not
Matt Putra, founder of Eightx, has documented what is found when settlement reports are actually pulled at client onboarding. At one client: $500,000 in unresolved Amazon deposits-in-transit. His description is precise: "Half a million dollars sitting in limbo because nobody was pulling the settlement reports and reconciling against the bank."
On investigation, the money was eventually accounted for, Amazon had initiated the payouts, the bank had received deposits. However, nobody had matched one to the other and the balance sheet was carrying half a million dollars in deposits in transit that existed as a ledger entry with no supporting reconciliation. The money was not missing. The professional exposure was. For the months that balance sat unreconciled, the CPA on the file could not explain what it represented. If that client had been audited, sold the business, or entered a dispute during that window, the CPA's position would have been indefensible from source. If you are the CPA who inherits that clearing account, it is nearly impossible to explain what the balance represents without reconstructing the settlement history from the platform's own source data.
Amazon settlement runs approximately every two weeks, subject to delivery based holds, account level reserves and account type. The cycles do not align with a calendar month. For any client whose previous bookkeeper was not pulling the settlement reports, the drift compounds silently and faster than the merchant's own reporting cadence. The clearing account balance is an inheritance, its direction is unknown.
A second client documented in the same blog tells the same story at a larger scale: a green cleaning products business doing more than $60 million in annual revenue. Amazon produces three primary seller-facing reports: the Summary Report, the Transaction Report, and the Business Report. Each uses different cut-off times, different fee categorizations and different treatment of returns. Putra's finding was that across these reports, the figures "don't match, typically 20% up or down" against internal records. At $60 million that is a $12 million variance that is not an error on the client's side. It is a structural feature of Amazon's reporting architecture. A seller comparing any two of these reports for the same period will find material differences that are not the result of anything the seller has done.
For the CPA serving that client, "the Amazon report says X" is not a single fact. It is at least three facts, each with different methodology and the right one depends on the question being asked. For federal tax purposes, the 1099-K applies and its gross figure is not taxable net revenue. For cash reconciliation, the settlement reports apply. For revenue recognition under ASC 606, the principal versus agent analysis determines whether gross or net treatment is appropriate: a principal recognizes revenue at the gross amount collected from customers; an agent recognizes the net amount retained after platform fees. The determination turns on control of the specified good or service before transfer. In multi-channel ecommerce, applying that test correctly depends on a reconstruction of what actually settled, from what source, under what platform terms.
A firm filing on the wrong Amazon report at $60 million of revenue is carrying a position it cannot substantiate from source. A forensic accountant reconstructing a case at that scale without source level reconciliation is producing an analysis that will not survive review by a counterparty who asks which report was used and why.
$25,000 in one month, in a public App Store review
In April 2025, a merchant reviewed the Intuit QuickBooks Online connector on the Shopify App Store: "The system is failing to accurately assign products, instead grouping them together in 'all sales' but currently assigning them in 'sales orders', which is leading to incorrect COGS figures on my P&L statement. On top of that, there's a $25,000 discrepancy in my Shopify sales this month due to improper integration, further complicating my financial reporting."
A public review, publicly dated, publicly quantified, with an Intuit reply on the record. A longer thread on the QuickBooks Community, on the native Shopify integration posting sales as net rather than gross, illustrates the same structural issue.
Integration tools, A2X, Link My Books, Synder, Webgility, Finaloop, are designed to post summarized platform data into the general ledger. Independent verification of whether the platform's underlying figures are correct, against bank receipts and the platform's own fee schedules, is outside their stated product scope. This is not a criticism of the tools. It is a description of what they do and what they do not do. The CPA firm that assumes posting is verification is the firm carrying the exposure when the posting turns out to be wrong.
$25,000 in one month at a single merchant, documented in a review anyone can read, is what happens when that assumption is wrong.
FBA overcharges and a closing window
A specialist FBA reimbursement industry now exists because a specific class of error within Amazon's settlement infrastructure is real, discoverable and recoverable, but only by those who know to look.
Amazon's automated fulfillment center systems assign each product to a fee tier based on measured dimensions and weight. When the measurement is incorrect, the fee is incorrect and the wrong fee compounds per unit shipped. Sellers who identify the error can submit remeasurement requests through Seller Central and recover via Amazon's reimbursement workflow.
GETIDA, one of the established reimbursement specialists, estimates that Amazon FBA sellers lose between 1% and 3% of annual revenue to FBA fee and inventory discrepancies. GETIDA is a commercial vendor with a financial interest in the size of the recoverable population, so the estimate should be read as an interested-party figure rather than an independent finding; that said, the existence of a commercially viable industry at recovery-fee percentages of 10% to 25% is itself evidence that the underlying error is material and widespread. These specialists, GETIDA, Refunzo, Carbon6's Seller Investigators, charge between 10% and 25% on recovered funds; GETIDA's published rate is 25% performance based.
On 23 October 2024, Amazon shortened the manual claim eligibility window for FBA warehouse lost and damaged claims from 18 months to 60 days. From 1 November 2024, Amazon began automatically reimbursing sellers for certain FC-lost inventory through a Reimbursements report in Seller Central. The automated reimbursement does not cover removal claims or shipment to Amazon claims, is not retroactive beyond approximately 2 September 2024 and does not eliminate the 60 day window constraint on manual claims for items outside the automated scope.
For a US CPA firm onboarding a new Amazon client, there is now a 60 day window inside which historical FBA errors remain recoverable through manual claim. For a quality of earnings or forensic engagement on an Amazon exposed business, the recoverable position at the date of instruction is materially different from what it was before October 2024. A mandate that would have permitted retrospective FBA recovery under the prior 18 month window may not permit it under the current one. The FBA settlement trail is a time-sensitive professional question, not a background consideration to be addressed once the primary reconstruction is complete.
No equivalent reimbursement infrastructure exists for Shopify, eBay, Etsy, or Walmart. The same class of fee error exists across every platform. On Amazon, a commercial industry catches it and recovers money. On every other platform, the overcharge sits inside the settlement total, embedded in the payout and is absorbed by the seller as a cost that is identified only in very rare cases.
Thrasio: 376 bank accounts and zero settlement reconciliation filings
On 28 February 2024, Thrasio Holdings Inc. and more than 200 affiliates filed prearranged Chapter 11 in the United States Bankruptcy Court for the District of New Jersey, before Judge Christine M. Gravelle. The plan reduced approximately $495 million of debt against an estimated $855 million of funded-debt exposure and committed up to $90 million of new financing. Plan confirmed 13 June 2024.
The CFO First Day Declaration of Josh Burke (Docket No. 38, filed 28 February 2024) describes the settlement architecture of a business operating at Amazon scale. At the time of filing, Thrasio operated 376 bank accounts across 15 banks in 5 countries, including 63 Payoneer accounts, 12 PayPal accounts, 4 Stripe accounts, and 38 OFX accounts, through which Amazon marketplace receipts flowed. AlixPartners had already reduced that count from a peak of 749 accounts pre-petition. The CFO's declaration states that the vast majority of Thrasio's brands sold their products exclusively on Amazon.
That is the settlement architecture of a business whose revenue depended almost entirely on one platform's payout mechanics, distributed across nearly 400 conduit accounts, managed by a restructuring firm that had already spent months rationalizing the account structure before the filing date.
What the docket does not contain is as instructive as what it does. No adversary proceeding against Amazon. No Rule 2004 motion targeting Seller Central data. No schedule entry treating Amazon payables or receivables as a quantified asset category. No declaration reconciling settlement reports across the 200-plus affiliate debtors. The Unsecured Creditors Committee's investigation, documented in the Disclosure Statement Objection (Doc. 354, 11 April 2024), focused on how the debtors lost over $3 billion in value in less than two years, specifically the 2020 insider tender offer and approximately $300 million of insider stock sales. Platform settlement mechanics are absent from the record.
Reconstructing the settlement trail across 200 plus Amazon dependent affiliates, operating through 376 accounts in five countries, would have required a methodology that does not exist anywhere in the US restructuring or forensic literature. No professional body has published one to date, nor has an advisory firm built one. AlixPartners, Thrasio's restructuring advisor with firsthand exposure to the settlement architecture, has published no post-mortem, no case study, and no methodology. The forensic technology platforms the profession relies on: IDEA, ACL, MindBridge, Relativity, carry zero Amazon, Shopify, or PayPal connectors. The absence of settlement reconciliation in the Thrasio docket is not a failing on anyone's part, it is the documented consequence of a capability that had not been built.
Across the aggregator cohort, the same pattern holds. Benitago Group, 28 affiliates in a Chapter 11 before Judge Sean H. Lane in the Southern District of New York, resolved in February 2024 with no adversary proceedings against Amazon. Packable Holdings (Pharmapacks), a top five Amazon third party seller with approximately 80% of revenue through the platform, liquidated in Delaware without a single publicly documented §542 turnover action against Amazon, Walmart, Target, or eBay for seller proceeds. Perch, Elevate Brands, and Branded Group resolved through lender-led mergers and equity conversions that kept platform settlement data entirely outside the public record. The silence is not isolated. It is the structural pattern of an entire generation of Amazon dependent businesses entering distress without the instrument to reconstruct their own settlement position.
What would a settlement reconciliation across 200-plus Amazon-dependent affiliates have found? No precedent exists for that reconstruction at scale. But one company's securities filings offer a partial answer.
What Shopify's reserve mechanism looks like from inside a case
Shopify's standard payout schedule operates on a 1 to 5 business day cadence for established merchants under normal circumstances. The Help Center documents custom payout schedules in the 5 to 20 business-day range for higher-risk accounts. A separate Help Center page on reserves describes case-by-case holds governed by the Terms of Service rather than any published standard schedule.
The mechanism operates as follows. Shopify exercises a contractual right to extend a merchant's payout schedule and place funds on hold, including past transactions not yet disbursed. This is documented in the Payments Terms of Service and confirmed in Shopify's own Help Center guidance. It is not a deviation from policy. It is the exercise of a right the merchant accepted when onboarding.
At the moment this happens, the merchant's accounting records contain no entry documenting the schedule change. The bank statement reveals only the effect: deposits that have stopped arriving. The amount withheld can be material. Reconstruction of what has occurred requires pulling Shopify's own payout history and reading the schedule transition in the platform's data directly.
For a forensic accountant, Chapter 11 trustee, or Chapter 7 trustee arriving at a case where the books have stopped reconciling, or where the trading record shows revenue that has not cleared to the bank, this mechanism is live in the data. Platform-held reserves are an asset class that standard asset tracing does not reach, because the asset sits in the platform's systems and visibility requires specialist capture directly from source. The same dynamic operates under partnership disputes, acquisition due diligence, and regulatory inquiry. Whenever the question is where the money actually went, and the business sold through a platform that holds reserves, the platform's own records are the primary source.
The Shopify reserve mechanism describes the structure. One company's public filings quantify what that structure looks like at nine-figure scale.
Wish: platform-held merchant funds, quantified at scale
Platform-held merchant receivables have been quantified at scale exactly once in US public records. Not by a bankruptcy schedule. Not by a §542 turnover action. By securities law disclosure requirements.
ContextLogic Inc., operator of the Wish marketplace, was a public company whose annual 10-K filings with the SEC carried a discrete balance sheet line titled "Merchants payable." That line represented funds owed by Wish to its merchant sellers for completed transactions that had not yet been disbursed. The figures, verified directly from ContextLogic's EDGAR filings, reached $620 million in FY2019 and ran between $74 million and $620 million across the six years ContextLogic was publicly reporting.
Every payment processor holds merchant funds for some period between transaction completion and payout; that is how settlement works. What makes the Wish figure significant is not the existence of a merchants payable balance but its scale, and the fact that it is visible in the public record solely because securities law required the disclosure. When a platform is a public company, its obligation to report this liability produces a nine-figure line item that investors, analysts, and regulators can examine. When the platform operator is private, or when the merchant sells through a platform operated by a third party, no equivalent disclosure requirement exists and the balance is invisible from outside the platform's own systems.
ContextLogic did not file for bankruptcy; it sold the Wish marketplace to Qoo10 in February 2024 and retained the shell entity. No seller-side litigation alleging nonpayment has been publicly identified. The Merchants payable balance was never tested judicially, never reconciled against individual seller claims, and never surfaced in any restructuring proceeding.
The implication for restructuring practice is the one the Thrasio docket confirms from a different angle. Platform-held merchant receivables are a real asset class. When a public company is required to disclose them, they appear as nine-figure balance sheet entries. When a private company enters restructuring, nobody has the instrument to find them, and they do not appear in the docket at all.
The CRA case, data retention, and the US precedent hiding in plain sight
In December 2025, the Canadian Federal Court of Appeal issued a preservation order in Canada (National Revenue) v. Shopify Inc., an interlocutory order with the underlying unnamed-persons requirement at 2025 FC 969 pending appeal. The Court required Shopify to preserve data from inactive Canadian merchant accounts that would otherwise have entered the platform's standard two-year deletion cycle. Reported by the Globe and Mail, BNN Bloomberg, and BetaKit in early January 2026.
A G7 tax authority needed data from deactivated merchant accounts to pursue tax obligations. Under Shopify's standard policy, that data would have been deleted at the 24-month mark. A Federal Court of Appeal intervened to preserve it.
The three implications for US professional engagements are direct. Deactivation is not a pause; it is the start of a deletion clock. Preservation can be compelled by court order, and the CRA case is now the reference point future cases will cite. A forensic engagement or trustee appointment arriving in month 25 of a deactivated account's dormancy arrives too late for data the platform has begun deleting.
One US bankruptcy precedent operates as legal infrastructure rather than case study. In Shaffer v. Amazon Services LLC (In re Potential Dynamix LLC), Bankr. D. Ariz. 2021, a Chapter 11 trustee pursued Amazon over unaccounted FBA inventory units. The facts were an inventory dispute, not a settlement reconciliation. But Judge Collins's holdings apply with equal force to withheld settlement funds: platform-held proceeds are property of the estate under §541; Amazon's Business Solutions Agreement liability cap is unenforceable as unconscionable under Washington law where damages are ascertainable; and post-petition account termination willfully violates the automatic stay. The trustee recovered $1,001,290 on a $6 million claim, losing the larger amount on burden-of-proof grounds. The burden-of-proof outcome is the finding that matters most for current practice: the legal template exists, but the reconstruction work that would have supported the trustee's burden of proof is what has not been built.
Shopify announced on 27 January 2026 that the Admin GraphQL Event interface and Admin REST events resource, which record merchant activity including order events and customer interactions, would be restricted to one-year retention, with data beyond twelve months no longer accessible. The platform's retention architecture is tightening. The CRA case established that the data exists and can be preserved on instruction. That instruction must come before the retention window closes.
Data preservation is a day-one decision for US forensic and restructuring practice on a multi-channel ecommerce business. Contemporaneous capture, cryptographically hashed at the moment of instruction, is available on the practitioner's timeline. Retrospective recovery is available on the platform's timeline. Those are not the same timeline.
The IRS does not yet have a direct equivalent of the CRA preservation case in the reported record. But it has the institutional precedent. In 2006, the IRS used a John Doe summons under §7602/§7609 to compel PayPal to identify US taxpayers with signature authority over offshore-issued payment cards. PayPal began delivering data to the IRS in January 2008. The IRS subsequently institutionalized its platform data flows through a Law Enforcement eRequest System specifically for eBay and PayPal data. No equivalent summons has been applied to Amazon, Shopify, or Etsy for merchant settlement histories. The direction of travel across G7 tax authorities, combined with the IRS's increasing deployment of third-party data-matching under the 1099-K regime, suggests the question of when is more pressing than the question of whether.
The tools exist. The reconstruction work does not.
The US legal system has mechanisms capable of compelling platform data in appropriate circumstances. §542 turnover actions under the Bankruptcy Code. Rule 2004 examinations. IRS John Doe summonses. The Schedule A TRO mechanism, which has compelled transaction histories and account freezes from Amazon, eBay, Shopify, Walmart, PayPal, and Stripe in thousands of IP counterfeiting cases.
None of these has been systematically deployed to reconstruct platform settlement positions in a large ecommerce restructuring. The Thrasio docket, the Benitago docket, the Packable docket: zero §542 turnover actions against Amazon for seller settlement proceeds, zero Rule 2004 motions targeting Seller Central data, zero IRS-style compelled data requests applied to merchant settlement histories in a restructuring context.
Before any of those tools can be deployed usefully, a professional needs to know what the settlement trail shows, what discrepancies exist, and what the documented position is. That foundation requires source-level reconstruction from the platform's own exports and the bank statement. It is work that happens before the legal question, not through the legal process. The §541 framework for platform-held assets has been developed in detail for cryptocurrency exchanges. Morrison and Foerster's Celsius alert and Proskauer's crypto-custody analysis establish the components. It has not been applied to ecommerce marketplaces, where the same structural question of who holds what, and how it is reconciled, governs a settlement infrastructure orders of magnitude larger.
Why the gap has not been closed
The gap has persisted because the problem sits at the intersection of three disciplines no single firm spans, the economics do not reward generalists, and the profession's own taxonomy has no category for the work.
Ecommerce accounting specialists understand platform behavior but are not forensic practitioners and do not produce evidence-grade deliverables. Forensic accountants understand evidence and procedure but do not specialize in ecommerce settlement mechanics. Integration vendors understand platform data but operate as software products, not professional services. The combination of ecommerce technical depth, forensic methodology, and the professional services register that makes a deliverable reliable in a practitioner's working papers is rare and slow to assemble.
Economically, the problem does not reward generalists. A CPA firm cannot profitably build deep expertise in Shopify settlement mechanics, Amazon SP-API schemas, PayPal transaction report formats, Stripe balance transaction types, and the bank statement parsing complexity that results from all of these hitting one bank account unless that is the entirety of what the firm does. The major US forensic practices have not built this capability because multi-channel ecommerce at typical engagement scale is below their minimum engagement economics, and because the expertise is acquired not by rotating CPAs through forensic engagements but by years of direct engagement with platform payout mechanics. A specialist ecommerce accounting firm cannot build it without fundamentally repositioning its commercial model away from the monthly fixed-fee work that is its core revenue.
The third reason is taxonomic, and it explains why the first two have persisted unchallenged. Professional bodies classify by industry chapter and engagement type. The AICPA Revenue Recognition Audit and Accounting Guide covers sixteen industry verticals: Aerospace, Airlines, Asset Management, Broker-Dealers, Construction, Depository Institutions, Gaming, Health Care, Hospitality, Insurance, Not-for-Profits, Oil & Gas, Power & Utility, Software, Telecommunications, and Time-Share. US ecommerce is a $1.23 trillion sector. It is not among them. The AICPA's Statement on Standards for Forensic Services No. 1 and AT-C §215 on agreed-upon procedures contain no ecommerce application guidance. The forensic analytics vendors have followed the same taxonomy: MindBridge's own support documentation confirms it integrates with QuickBooks, Xero, and Sage Intacct; no Amazon, Shopify, PayPal, Stripe, or Etsy connector exists.
Ecommerce settlement verification does not fit an existing industry chapter or an existing engagement schema. No standard-setter has defined the methodology. No vendor has built the tool. The gap has not been closed because the profession has not yet named it.
Software reconciles. A named professional signs the report.
CPAs who use A2X and Link My Books will arrive at this section with the question already formed.
Reconciliation software posts what the platform tells it. The more sophisticated products now include internal reconciliation reporting and analytics on top of that posting. None of this constitutes independent verification of whether the platform told the truth. A subledger built by the same vendor that posts the data cannot independently check its own output, not as a criticism of the tools, but as a description of what independent means in professional services terms.
The professional standards framework that governs assurance engagements, AICPA SSFS No. 1 and the agreed-upon procedures framework more broadly, is built on a structural distinction: the party producing the work is not the party attesting to it. That distinction is not available to a software product. It is available to a named professional standing behind a third-party finding. The difference is not capability. It is independence of origin, and it is the difference that makes a deliverable adoptable into a regulated firm's working papers.
What source-level reconstruction surfaces, concretely: a reserve hold that the accounting software recorded as an expense, which the bank statement shows was never debited, which the platform's own payout history shows was released two settlement periods later into a different bank account. A chargeback reversal that the integration tool posted as a refund, understating net revenue and creating a permanent variance in the clearing account. A settlement period where the platform's payout fell short of the calculated net by the exact amount of an FBA dimensional fee overcharge that nobody had identified because the fee was embedded in the settlement total and was never decomposed against the fee schedule. These are not hypothetical categories. They are the exception types that reconstruction isolates, categorizes, and documents with a reason code and a recommended action.
The decision point
The IRS has published its position on 1099-K. A Tax Court has enforced it. The IRS's own Inspector General has identified hundreds of thousands of unresolved discrepancies, and the matching infrastructure that flags them is structurally blind to overpayment. Courts have established that platform data preservation can be compelled by order. The South Carolina Supreme Court has confirmed that Amazon's control over third-party transactions is so comprehensive that collection obligations attach. Shopify is tightening its retention architecture. Amazon has compressed the FBA claim window from 18 months to 60 days for warehouse claims. Thrasio and the aggregator cohort have demonstrated what a platform-concentrated settlement architecture looks like when it enters restructuring without source-level reconstruction. The integration tools the profession relies on are designed to post, and they post what they are given.
Three independent clocks are running against ecommerce clients simultaneously. The only engagement that stops all three is one that captures, preserves, and reconstructs from source before any of the windows close. The three clocks
Three independent clocks are running against ecommerce clients simultaneously. The IRC §6511 refund window closes on overpaid tax that no one has identified. The Shopify data retention window closes on source records that no one has captured. The Amazon FBA claim window closes on recoverable overcharges that no one has filed. The only engagement that stops all three is one that captures, preserves, and reconstructs from source before any of the windows close.
What this analysis does not cover
The overpayment share within TIGTA's non-converted discrepancies has not been measured in any published dataset. This article infers its existence from structural conditions, not from direct observation. The aggregator docket analysis is based on public filings and may not reflect sealed or confidential settlement activity. The Eightx and QuickBooks App Store examples are individual observations, not a statistically representative sample. The analysis addresses US-centric platforms and federal tax exposure; the international settlement landscape, including cross-border VAT and customs duty treatment, is outside its scope. These boundaries do not diminish the structural findings. They define the territory within which the findings hold.