Webshop bookkeeping in e-conomic: sales, payments and reconciliation

A webshop gives the books two streams to keep track of: the sales, meaning the orders, and the money, meaning the payouts from Shopify Payments, Stripe, MobilePay, Klarna or Nets. The two arrive on different days and with different amounts, which is why webshop bookkeeping so often ends in differences. This guide shows how to keep them apart in e-conomic, make them meet on a clearing account that comes to zero, and reconcile it all every month.

Two streams: the sales and the money

• The sale is the order: customer, goods, shipping, discount and VAT. It belongs to the VAT period in which the order was placed and becomes an invoice or an entry on a revenue account.
• The money comes from the payment provider, often a few days later and pooled for many orders. The payout is the sales minus fees and refunds, so it is never the same amount as the revenue.

If you book the payout as revenue, revenue and VAT come out too low and the fees disappear. If you book both the orders and the payout as sales, the sales count twice. The rule is simple: the orders are the sales, and the payout is a payment.

The sales: pooled per day or one invoice per order

There are two ways to book the sales:

• Pooled per day or per payout. The day's sales are booked as one entry on a revenue account. It is quick, but there is no customer and no invoice, so refunds, gift cards and VAT per country (OSS) must be worked out separately.
• One invoice per order. Each order becomes an invoice in e-conomic with customer, lines, shipping, discount and VAT. A refund becomes a credit note on the right invoice, and the payment can close the invoice.

If you have more than a handful of orders a week or customers in other EU countries, one invoice per order is almost always right. How it is done on each platform is in the guides for Shopify, WooCommerce and Magento 2.

The money: one clearing account per payment provider

Create a balance sheet account in e-conomic for each payment provider, such as "Shopify Payments receivable" or "Stripe receivable". Everything that happens at the provider is booked through that account:

1. The payments close the invoices: debit the clearing account, credit the debtor.
2. Refunds go the other way: credit the clearing account, debit the debtor, against the credit note.
3. The fees are booked on a fees account with the VAT the provider's fee invoice states, and credited to the clearing account.
4. The payout to the bank is credited to the clearing account and debited to the bank.

When everything for a payout is booked, the clearing account stands at zero. If an amount is left, a payment, a refund or a fee is missing.

Example: one payout from Shopify Payments

The payout covers three orders totalling DKK 1,575.10, a refund of DKK 199.00 for an earlier order and fees of DKK 38.75. The bank receives DKK 1,337.35:

Revenue and VAT came with the invoices when the orders were placed. The payout does not change them; it only moves the money from the provider to the bank. The details for each provider are in the guides for Shopify Payments, Stripe and MobilePay.

VAT: Denmark, the EU and OSS

• Customers in Denmark pay Danish VAT, 25%.
• Consumers in other EU countries: below EUR 10,000 a year in total distance sales to the EU you charge Danish VAT. Above the threshold you charge the buyer's country's VAT and report it through the One-Stop-Shop (OSS), with a VAT zone per country in e-conomic.
• Business customers in the EU with a valid VAT number are normally invoiced without VAT under the reverse charge.
• Customers outside the EU are invoiced without Danish VAT as exports.

The VAT in the books must be the VAT the webshop actually charged the customer. So the webshop's tax settings must match your registration before it makes sense to look at e-conomic.

Reconciling every month

• The clearing accounts stand at zero, or at exactly what the provider has not paid out yet.
• Open debtor entries match orders that really are unpaid, such as invoice or bank transfer. An old open entry for a card payment means the payment did not close its invoice.
• Revenue in e-conomic matches the webshop's sales report for the month, less refunds.
• VAT matches the webshop's tax report, country by country if you use OSS.
• The bank matches the provider's list of payouts.

Common mistakes

• The payout booked as revenue. Revenue comes out too low by the fees and refunds, and VAT with it.
• Sales counted twice, because both the invoices and the payout are booked as sales.
• Fees deducted from revenue instead of standing on a fees account.
• One clearing account for several providers, so it is impossible to see which payout is missing something.
• Refunds without a credit note, so revenue is too high and the debtor never comes to zero.

Questions about webshop bookkeeping

Which date should the sale have?

The order date, or the date the goods were delivered if you invoice on shipping. Not the payout date: then a sale can land in the wrong VAT period when a payout crosses a month end.

Do fees from payment providers carry VAT?

It depends on the provider and where it is based. Book the fees with the VAT stated on the provider's fee invoice or report, and ask your accountant if the provider is abroad.

Can we just book the sales pooled per day?

Yes, if you sell little and only to Denmark. As long as there are few refunds and no OSS VAT, it can be enough. When sales grow, or customers in other EU countries arrive, one invoice per order is easier to keep track of.

Automatically with 2app

2app can do both streams automatically. Webshop apps such as Shopify to e-conomic, WooCommerce to e-conomic, Magento 2 to e-conomic and PrestaShop to e-conomic turn the orders into invoices in e-conomic. Payment apps such as Shopify Payments to e-conomic, Stripe to e-conomic and MobilePay to e-conomic put the payouts in a cash journal, where the payments close the invoices and the fees stand on their own. A payout that does not match to the øre is stopped and shown.

See all webshop integrations and payment integrations.