The accounting of an online shop, from the sale to the bank

What changes when you sell online instead of over a counter

In a counter business the sale and the payment are almost always the same moment: the customer pays and the money lands in the till or the card reader. In an online shop that simultaneity disappears. The order is confirmed on the website, the payment is processed by a gateway (or by the marketplace itself, if that is how you sell), and that money does not travel straight to your account: the gateway holds it, deducts its fee and pays you later, usually grouped with other orders from the same period.

None of this changes your tax obligations in the slightest: you are still the one selling, invoicing, and keeping the accounting of your business under double entry rules if that applies to you. What changes is the mechanics of the record, because now there are three different dates to log instead of one, and mixing them up is behind almost every mismatch that shows up when you close the month, however tidy the rest of your bookkeeping already is.

A simple example makes it clear: a 60 euro order confirmed on a Tuesday may show as captured by the gateway that same Tuesday, and yet not reach your bank until Friday, mixed in with twenty other orders, as a single net line of 1,140 euros. If your books only look at Friday and that one line, Tuesday's sale never gets recorded as such, and with it the VAT that belongs to that date disappears too, which is exactly the kind of gap a tax inspection looks for first.

The sale, the payment and the bank credit are three different facts

It helps to keep three moments mentally separate, because each generates its own entry and none replaces the other two. First, the sale: the customer confirms the order and you issue its invoice, regardless of how and when you get paid. Second, the payment: the gateway captures the gross amount of that sale at the same moment or a few minutes later, and keeps its fee. Third, the credit to your bank: the gateway pays you the net of a batch of sales, usually every few days, in a single line of your statement that says nothing about the individual orders behind it.

If you only book what shows up in the bank statement, two things get lost: the output VAT of each sale and the gateway's fee, which is its own deductible expense, not a silent deduction from the deposit. And VAT does not wait for the money to reach your bank. Article 75.One.1 of the VAT Act makes the tax chargeable, on supplies of goods, when the product is «placed at the disposal of the buyer»; and article 75.Two brings that forward when there are advance payments made before the taxable event, in which case the tax «shall become chargeable at the moment of collection, in full or in part, on the amounts actually received», with the sole exception of the supplies of goods of article 25 (the intra-EU ones). In a shop that charges the card on order confirmation and ships afterwards, that is exactly the normal case: the gateway's capture IS the chargeable event.

What never governs is the third date, the one the gateway settles into your bank: that deposit arrives days later, grouped and net, and it moves the chargeable event of no sale at all. The useful contrast, then, is not «sale versus payment», but «the date of the sale or of the customer's payment» against «the date the money lands in your account». Treating the net bank amount as if it were the sale is the fastest way to under declare.

With numbers: you sell a 121 euro product, VAT included (100 base plus 21 of VAT). The gateway charges a fee of 1.5% plus 0.25 euros, that is 2.065 euros. In your books the sale is recorded for the full 121 euros, with its 21 euros of output VAT; the fee is recorded separately as a 2.065 euro expense; and what finally lands in the bank, 118.935 euros, is the result of subtracting one from the other, not a new figure you have to invent.

The grouped entry: what the Commercial Code allows

The good news is that Spanish commercial law does not demand one entry per order. Article 28.2 of the Commercial Code says the Diario records the business's operations day by day, but it allows «the joint recording of the totals of the operations for periods of no more than a quarter, provided their detail appears in other matching books or records». In other words, you may summarise, as long as the detail exists somewhere and can be reconstructed.

In practice this means one sales entry per day or per settlement batch, not per order, backed by the detailed export from your shop platform or your gateway, always under double entry bookkeeping: debit the amount collected or receivable, credit the sale and the output VAT. The usual mistake is not grouping itself, which the law allows, but grouping without keeping the detail that backs it up.

That «detail appearing in other books» has a very concrete shape in an ecommerce business: the order list exported from your shop platform, with date, order number, amount, customer and VAT rate applied, column by column. Keeping that file month after month, even when the accounting entry itself is a single line, is what turns the summary into a lawful summary rather than an unsupported figure.

It is worth keeping two different summaries apart. The one in article 28.2 is an accounting summary and lives in the Libro Diario, one of the two books that article 25.1 of the Commercial Code declares mandatory, alongside the book of inventories and annual accounts. The one in article 63.4 of the VAT Regulation is a tax summary and lives in the record book of issued invoices: there, the invoice by invoice entry may be replaced by summary entries covering consecutively numbered invoices issued on the same date, provided that identifying the recipient is not mandatory on those invoices and that the tax point of all of them falls within the same calendar month. The content of that summary entry is set by the rule itself: the issue date, the global taxable base for each rate, the rates applied, the global tax amount, and the first and last numbers of the invoices grouped.

And there is a duty almost nobody writes into the calendar: the detail that backs the summary has to be kept. Article 30.1 of the Commercial Code requires books, correspondence, documentation and supporting records to be kept for six years from the last entry made in the books, and article 30.2 makes clear that closing the business does not release you from it. An order list that lives only inside the platform's dashboard stops meeting that condition the day you stop paying the subscription, so exporting it every month is not an accountant's quirk: it is the evidence.

Gateway fees, shipping and packaging: each to its own account

An online sale carries costs a counter sale does not, and each one deserves its own accounting entry instead of getting lost inside the net deposit. The payment gateway's fee (Stripe or another provider) is a service rendered to you, so it is a deductible expense with its own invoice, which usually arrives with no Spanish VAT amount when the provider is not established in Spain, so its treatment in the modelo 303 is not that of an ordinary Spanish invoice and is worth checking invoice by invoice. The cost of shipping, when you absorb it yourself, is a separate expense; if instead you pass it on to the customer within the sale price, that shipping charge becomes part of the taxable base of your invoice and carries the same VAT rate as the product.

Packaging and storage costs follow the general rules of any operating expense. Lumping these three items into a single «selling costs» account works while the business is small, but as it grows it stops you seeing whether the margin is being eaten by the gateway fee, by shipping, or by the product's own cost.

Picture a 40 euro order with 5 euros of shipping charged to the customer added on top: the invoice documents 45 euros of taxable base with its corresponding VAT, not 40. The actual cost of shipping that parcel, say 6 euros paid to the carrier, is a separate expense with its own invoice, and the gap between what you charged for shipping and what you paid the carrier is simply part of the business result, not an adjustment buried inside a single account.

Your payment provider's payout never matches your sales

This is the surprise that most often causes a scare when reconciling: the amount that shows up on the bank statement almost never matches the sum of sales for a specific day. Your payment provider's payout groups sales from several days, deducts its fee, may include refunds processed within the same batch and sometimes withholds a share as a reserve fund released later. Comparing «Monday's sales» against «Monday's deposit» and expecting them to match is, almost always, the reason for the mismatch.

The fix is not forcing the numbers to match by hand, but treating each payout for what it is: a collection into a bridge account (the gateway, handled almost like another bank) that is later transferred to your real bank account through its own bank reconciliation. With that bridge account, the sale entry, the gateway collection entry and the final deposit entry stay linked and traceable, and the bank statement stops being the only document you try to match everything against.

In practice, a week with fifty orders can end up settling as two or three separate payouts in the bank, each one its own mix of sales, fees and the odd refund. Without the bridge account, matching those two or three lines against fifty orders by hand is a task that grows out of control; with it, each payout is reconciled against the gateway's outstanding balance, not against the whole list of orders.

Refunds, cancellations and chargebacks

An ecommerce business has a return rate a counter business rarely reaches, and each type of incident is booked differently. A refund already paid forces a correction: article 80.Two of the VAT Act modifies the taxable base when an operation is wholly or partly undone, and article 89.One requires the correction to be made as soon as that circumstance is noticed. When the correction lowers the VAT originally charged, article 89.Five offers two routes: asking the tax agency to amend the self assessment of that period, or regularising it in the return of the period in which the correction has to be made, or in later ones for up to one year, refunding the customer the VAT charged in excess. A cancellation before the order ships depends on whether the money actually came in: if the gateway already captured the payment, the tax was triggered by article 75.Two and the cancellation is handled just like the refund above, under article 80.Two and its credit note; if the card was only authorised and never captured, nothing was triggered and there is nothing to correct. A chargeback, when the cardholder disputes the charge with their own bank, is decided on the same axis as the cancellation: what happened to the operation, not what happened to the money. If the operation is undone, because the goods come back or were never delivered, it is article 80.Two again with its credit note, exactly like the refund above. If the sale still stands and the only thing missing is the payment, the taxable base can only be reduced through the bad debt route of article 80.Four, which never applies on its own and carries conditions and deadlines of its own: one year since the tax was triggered without getting paid (six months if your turnover of the previous year stayed below the 6,010,121.04 euros that same article sets), the unpaid amount recorded in your VAT books, a customer acting as a business or a taxable base above 50 euros, and a claim for payment made through the courts, by notarial demand or by any other means that reliably proves it, with the adjustment made within the following six months and reported to the tax agency. And those conditions are not the last word, because there is a veto an online shop runs into often: article 80.Five does not allow the taxable base to be modified in the cases of that fourth paragraph when the customer is not established in the Spanish VAT territory, nor in the Canary Islands, Ceuta or Melilla, so an unpaid sale to a consumer in another EU country is left without that route. The only carve-out written into that same paragraph is a bad debt arising from insolvency proceedings opened by a court of another Member State under Regulation (EU) 2015/848, which is corrected through article 80.Three, the insolvency route. The chargeback handling fee the gateway charges you is, in both cases, a separate expense with its own invoice.

Mixing up these three leads to reaching for the wrong provision: correcting under article 80.Two a sale that still stands and that nobody has undone, writing off as lost the VAT of an operation that really was undone and could have been corrected, or leaving unrecorded the fees that did leave your account. The question that sorts them out is not how the money moved, but whether the operation is still alive.

A common case: a customer returns an 80 euro product two months after buying it. Under the second route of article 89.Five, the credit note is issued and reflected in the return of the period in which you accept the return, deducting those 80 euros and their VAT from that quarter, leaving the quarter already filed untouched, and refunding the customer the VAT charged in excess. Had the same customer instead disputed the charge directly with their bank, without going through your returns process, the first thing to change is the money: the gateway pulls those 80 euros out of your next payout and adds its chargeback handling fee, which an ordinary refund does not carry. The second thing, and the one that actually decides the VAT, is what happened to the operation: if the goods come back or were never delivered, it is undone and you correct under article 80.Two, with the same deduction in the period's return you have just seen; if the customer keeps the goods and what you have is an unpaid sale, that withdrawal from the payout is no credit note at all, and the VAT you charged can only be recovered through article 80.Four, meeting its conditions and its deadlines, and only if that customer is established in the Spanish VAT territory, in the Canary Islands, Ceuta or Melilla: if they bought from another EU country, article 80.Five closes that door.

The VAT on each sale follows where the parcel goes

The VAT rate on an online sale does not depend on where your shop is based, but on who is buying and to which country the product ships. To a final consumer in Spain, the ordinary Spanish VAT of the product applies. To a final consumer in another EU country, as long as you stay under the 10,000 euro yearly threshold on distance sales already covered by that guide, you still charge Spanish VAT; above it, taxation at destination kicks in along with the one stop shop return. To a business in another EU country, goods leaving Spain for another Member State go out with no Spanish VAT, but not under the reverse charge, which is the mechanism for services: this is an exempt intra-EU supply under article 25 of the VAT Act. The exemption is not automatic and carries two conditions written into that same article: the buyer must have given you a VAT identification number issued by another Member State, and you must include the transaction in the recapitulative return, modelo 349. The sale is also reflected in the quarter's modelo 303.

These three situations coexist within the same shop if you sell to several countries, so the sales ledger needs to record the destination and the type of customer of every order, not just its amount.

Think of three orders on the same day: one to a private individual in Valencia, carrying the usual 21% Spanish VAT; another to a private individual in Lyon, still carrying the same 21% Spanish VAT as long as you stay under the 10,000 euro threshold; and a third to a German business that gives you a VAT number issued by another Member State, which goes out with no Spanish VAT as an exempt intra-EU supply, with its own line in modelo 349. Three orders, three different treatments, and all three have to be identified as such in the sales ledger, not merged into a single «today's sales» column.

Month end for an online shop, in eight checks

Before closing a month of ecommerce it is worth running through eight points: 1) that every sale of the period has its invoice, recorded one by one in the issued invoices book or grouped into the summary entry of article 63.4 of the VAT Regulation when both of its conditions are met; 2) that the whole month's gateway fees are booked as an expense, with their own invoice; 3) that every bank deposit of the month is reconciled against the gateway's bridge account, not directly against the sales; 4) that refunds carry their credit note in the period they happen; 5) that any chargebacks are identified and not confused with ordinary refunds; 6) that the VAT on each sale matches the correct destination country and customer type; 7) that sales outside Spain above the threshold are flagged for the one stop shop return; and 8) that the balance of the gateway's bridge account, once the payouts already collected are deducted, matches what its dashboard says it still owes you.

Running through this list every month, rather than only at year end, is what stops a small January mismatch from turning into a December problem.

Setting a fixed calendar day for this checklist, say the first five business days of the following month, has an extra benefit: any credit note, chargeback or foreign sale you might have missed surfaces with enough time to fix it before the modelo 303 deadline, instead of being discovered on the 19th of the filing month. A shop that grows from a handful of orders a week to dozens a day usually notices the value of this routine the first time a gateway payout arrives split across two calendar months: without a fixed closing day, half of that batch risks being booked twice, or not at all.

How kontora handles it

kontora turns every order into its invoice through the Verifactu chain and groups the day's sales by channel into a single diary entry, which is more than article 28.2 asks for. Orders come in through the kontora API from your shop, or through a CSV file: there is no native integration with Amazon or with Shopify, and we do not advertise one. Payouts are reconciled today against sales through the Stripe path. The bank statement comes in through the norma 43 file you download from your online banking: there is no automatic bank connection and we announce no date for one.

Frequently asked questions

Keep reading