Debit and credit explained
Soll and Haben are the two sides of a journal entry. Soll is the left side (debit), Haben the right (credit). That is the complete definition, and it is hard to accept precisely because the two German words appear to mean something else entirely.
The words do not mean what they say
The most common misreading: "Soll" sounds like obligation, "Haben" like possession. So surely what you have belongs on the Haben side.
It does not. When your customer pays 11,900 euros, the incoming value sits in Soll, not Haben. The revenue, the thing you actually earned, sits in Haben. Anyone trying to memorise this through the literal meaning of the words memorises it backwards.
The terms are historical remnants of the view from a current account, the perspective of the party you are settling with rather than your own. For daily work, the only reliable mnemonic is the plainest one:
Soll is left. Haben is right. Both sides are equal.
Everything else follows from that, and no mnemonic built on "owed" versus "owned" survives the first complicated case.
An example with real numbers
A stablecoin payment of 11,900 euros gross, 19 percent VAT:
1370 Verrechnung Krypto S 11.900,00
8400 Erlöse 19 % USt H 10.000,00
1776 Umsatzsteuer 19 % H 1.900,00
Left: 11,900.00. Right: 10,000.00 + 1,900.00 = 11,900.00. The entry balances.
Worth noting: one side may consist of several accounts. An entry is not limited to two accounts, only to both sides summing to the same amount. This is where "double-entry bookkeeping" is often misunderstood: it means two sides, not two accounts.
The rounding trap that fails quietly
The gross amount is given; net and VAT are derived from it. And here sits an error that accumulates over a month.
Rounding both values independently produces differences:
11,900.00 / 1.19 = 9,999.9999... → rounded 10,000.00
11,900.00 * 0.19 / 1.19 = 1,899.9999... → rounded 1,900.00
Here it happens to work out. At 3,046.40 gross with 7 percent it may not: net and tax, each rounded on its own, sometimes sum to a cent more or less than the gross. Then the left side no longer equals the right, and the entry is not an entry.
So the clean rule is: round one value, derive the other as the difference. Round the net commercially, and compute VAT as gross minus net, never both independently. That is exactly what our rule does, and the source comment says why: a rounding rule that lets Soll drift from Haben is not an accounting system, it is a bug with a spreadsheet attached.
A balanced entry can still be wrong
Writing this article surfaced a defect in our own product that belongs precisely here, so we would rather write it up ourselves.
Our bookings were always correct: three lines, Soll equals Haben, to the cent. What was wrong was their translation into the DATEV export file. In the EXTF format a single line is already a complete journal entry, because DATEV posts the contra side automatically to the account named in Gegenkonto. We were writing each side as its own line and giving every one of them a contra account. Replaying the resulting file the way DATEV reads it:
intended 1370 11,900.00 S 8400 10,000.00 H 1776 1,900.00 H
exported 1370 21,900.00 S 8400 18,403.36 H 1776 3,496.64 H
Every individual line looked plausible on its own. The total was roughly double.
The lesson is the real reason this section exists: Soll equals Haben is a necessary condition, not a sufficient one. A batch can balance perfectly and still post the wrong amount. So our new regression test no longer checks whether the file agrees with itself. It replays the exported lines the way DATEV would execute them and compares the balance per account against what the rule computed. The old test could not find this, because it rebuilt the same mapping and compared it with itself.
Fixed as of 3 September 2026. That it could happen at all is exactly why a first import test at a real tax firm sits on our list rather than counting as done.
Frequently asked questions
Why is it called "double-entry" bookkeeping? Because every transaction is recorded on two sides, not because it is booked twice. The balance and its origin are captured simultaneously, which exposes errors a simple list swallows.
Can one side consist of several accounts? Yes. The entry shown above has one account in Soll and two in Haben. All that is required is that both sides sum to the same amount.
Is Soll always an increase? No, it depends on the account type. On a balance-sheet account Soll means an increase; on a revenue account the earnings sit in Haben. This is why "Soll is left" holds up better than any interpretation based on meaning.
What does the S or H in a DATEV export file refer to? It applies to the account in the Konto field, not to the line as a whole. DATEV posts the contra side automatically to Gegenkonto. Miss that, and you export exactly the bug described above.
This post is part of a glossary series covering the terms that come up constantly in crypto bookkeeping: SKR03, GoBD, EXTF, debit and credit, reverse charge. It is not tax advice.