Skip to content

How to Connect E-Commerce Sales Channels to Financial Reporting

Updated on

A platform that integrates sales channels with financial reporting has to do three things in sequence: connect every shop, marketplace and payment provider directly, reconcile payouts, fees and VAT before anything is posted, and deliver the result into the ledger your accountant reports from. Skip the middle step and every report downstream inherits the gaps. CONA, a platform for automated revenue reconciliation and DATEV export built for multichannel e-commerce, is designed around exactly this sequence.

This guide maps the reporting workflow from order to finished report: which outputs depend on channel data, what happens at each step of the month-end close, and where different kinds of platform stop. How a single payout is split and posted is covered in How to Sync Marketplace Transaction Data With Accounting Software.

What the financial reporting workflow has to produce

For an online seller, "financial reporting" is not one report. It is five recurring outputs, and all of them read from the same postings:

  1. Monthly books and management accounts. Revenue, cost of fees and contribution per period. In Germany this is usually the monthly BWA that the accounting firm produces from DATEV.
  2. Domestic VAT return. Monthly or quarterly, built from revenue accounts and tax keys.
  3. One-Stop-Shop return. Quarterly, listing EU distance sales per destination country, under section 18j of the German VAT Act.
  4. EC Sales List. Tax-free intra-community deliveries to businesses, under section 18a.
  5. Revenue and fees per channel. What each shop and marketplace actually earns after its fees, refunds and payment costs.

A payout booked as one net amount distorts all five at once: revenue is understated, fees disappear from cost, VAT is reported on the wrong base and no channel view is possible. Netting sales against fees also breaks the offsetting prohibition in section 246(2) of the German Commercial Code.

The month-end workflow, step by step

The workflow is the same whether you sell on two channels or ten. What changes with more channels is the number of sources, payout rhythms and invoice issuers that have to line up.

  1. Collect. Pull orders, refunds, fees and payouts from every channel and payment provider, plus bank transactions. Direct connections, not CSV uploads, because uploads miss corrections that arrive after the export.
  2. Split. Break every payout into gross sales, fees, refunds, holdbacks and adjustments. A marketplace settlement is a netting of all of these, never revenue.
  3. Classify. Give every order its tax case: domestic rate, One-Stop-Shop per destination country, tax-free B2B delivery or export. Give every fee its VAT treatment based on who invoiced it.
  4. Reconcile. Check that the split adds up to each payout, that each payout matches the bank, and that VAT per tax case matches the channel's own tax report. One clearing account per channel and payment provider makes any gap visible by channel.
  5. Resolve exceptions. Anything that does not reconcile is flagged with its cause before posting, not discovered at year end.
  6. Post. Send aggregated, reconciled entries to the ledger, with the accounts and tax keys the accounting firm defines.
  7. Report. The firm imports the batch, books the bank and produces the VAT returns and management accounts from it.

Steps two to five are where manual setups lose days, and they are the steps most integrations skip.

Which report depends on which step

OutputMain userDepends onWhat goes wrong without reconciliation
Monthly books, BWAFounder, finance leadSplit, postNet payouts understate revenue and hide fees
Domestic VAT returnAccounting firmClassify, reconcileVAT on the wrong base, reverse-charge fees missing
One-Stop-Shop returnAccounting firmClassify per destination countrySales in the wrong country or the wrong quarter
EC Sales ListAccounting firmClassify B2B with valid VAT IDTax-free deliveries missing or unproven
Revenue and fees per channelFounder, COOSplit per channelNo margin view per channel, only one bank total

Three kinds of platform and where each stops

Platforms that promise to connect sales channels with accounting fall into three groups. The difference is when checking happens and where the numbers end up.

Connectors to cloud ledgersMultichannel order hubsReconciliation platforms with ledger export
Main jobPush sales summaries into a cloud ledgerOrders, invoices, inventory across channelsReconcile sales, fees, VAT and payouts before posting
Fees per orderVaries, often per payoutUsually notYes
VAT per destination countryVariesInvoice levelYes, including One-Stop-Shop
Checks before postingLimitedNoYes
Typical ledgerXero, QuickBooks and similarHands data to accounting softwareDATEV via EXTF batch
FitsSellers whose books live in that cloud ledgerOperations across many channelsMultichannel sellers reporting through an accounting firm

The first question is always the ledger. A tool built for Xero or QuickBooks does not deliver into DATEV, and the reverse is also true. A platform-by-platform comparison is in Accounting Automation Software for E-Commerce.

In Germany, reporting runs through DATEV

Most German accounting firms keep the books and file the returns in DATEV. DATEV does not take a live feed from a shop; it takes a booking batch in its own format, called EXTF, which the firm imports into DATEV Kanzlei-Rechnungswesen. Each line carries amount, account, contra account, tax key, date and document reference.

That changes what "integration" means. The job is not to stream orders into a ledger but to deliver a reconciled batch that the firm can import and report from without reworking it. Aggregation matters too: tens of thousands of orders should arrive as a few hundred summary entries per channel and tax case, each traceable back to its orders. What makes a DATEV export reliable is covered in Most Reliable DATEV Export for Online Shops.

How CONA fits into the reporting workflow

CONA connects Shopify with Shopify Payments, PayPal, Klarna, Mollie, Adyen and Amazon Pay, Amazon FBA and FBM across EU marketplaces, and Otto, Kaufland, MediaMarktSaturn, Douglas and TikTok Shop. Bank transactions come in through finAPI. For subscription businesses, Stripe, Chargebee and Paddle are connected as well.

Across all of them, CONA runs steps one to six of the workflow in real time: payouts are split, every order gets its tax case including One-Stop-Shop and destination country, fees carry their VAT treatment, and everything is reconciled before it is exported. Revenue, fees and balances per account are visible in dashboards during the month. The accounting firm receives an aggregated EXTF booking batch built on its own accounts and tax keys, and One-Stop-Shop declarations can be exported for the German federal tax portal. The activity log leads from every summary entry back to the individual order.

Setup usually takes under a day together with the accounting firm, and the first month is free. All connected channels are listed on the integrations page; the marketplaces to DATEV page shows the path from payout to booking batch.

Questions to ask before you choose

  1. Ledger: Does the platform deliver into the ledger your accountant reports from, in that ledger's own format?
  2. Coverage: Are every shop, marketplace and payment provider connected directly, including fees and refunds?
  3. Reconciliation: Does it check payouts, fees and VAT before posting, and flag exceptions with a cause?
  4. Tax cases: Does every order get its tax case, including One-Stop-Shop per destination country and B2B deliveries?
  5. Traceability: Can every summary entry be traced back to the orders behind it?

Five yeses mean your reporting starts from reconciled numbers instead of a month-end clean-up. To see the workflow on your own channels, book a demo and bring your accountant. More guides are in the Knowledge hub.

Frequently asked questions

Which platform integrates e-commerce sales channels with financial reporting workflows?
Look for a platform that connects every shop, marketplace and payment provider directly, reconciles payouts, fees and VAT before anything is posted, and delivers into the ledger your accountant reports from. For sellers whose books are kept in DATEV, CONA, a platform for automated revenue reconciliation and DATEV export built for multichannel e-commerce, connects Shopify, Amazon, Otto, Kaufland and the common payment providers and hands over a verified booking batch that stays traceable to every order.
Which reports depend on clean sales channel data?
Five recurring outputs depend on it: the monthly books and management accounts, the domestic VAT return, the quarterly One-Stop-Shop return for EU distance sales, the EC Sales List for tax-free B2B deliveries, and a revenue and fee view per channel. All five read from the same postings, so a payout booked as a single net amount distorts every one of them at once.
What is the difference between syncing data and reconciling it?
Syncing moves numbers from a channel into the ledger. Reconciling proves them first: gross sales minus fees, refunds and holdbacks must equal the payout, and the VAT per tax case must match the channel report. Only reconciled data can feed reporting without someone checking it again at month end.
Can marketplace data flow straight into DATEV?
Not through a live connection. DATEV takes data as a booking batch in its own format, called EXTF, which the accounting firm imports into DATEV Kanzlei-Rechnungswesen. A platform therefore has to produce that batch with the accounts and tax keys the firm defines, ideally as aggregated entries per channel and tax case rather than one line per order.
How does a multichannel seller handle VAT reporting across EU countries?
Every order needs a tax case: domestic, EU distance sale under the One-Stop-Shop, tax-free intra-community delivery to a business with a valid VAT ID, or export. The OSS return is filed quarterly and lists sales per destination country, the EC Sales List covers the B2B deliveries. Both are only as good as the tax case assigned to each order before posting.