Bookkeeping, SIE4 and BAS.

SIE is the Swedish interchange format for accounting data, and it is how a period of invoices gets from one company's software into the package their accountant actually keeps the books in — Fortnox, Visma, BL Administration or another one.

It is a plain text file of records, each beginning with a hash. A header says who the company is, which program wrote the file, which character set it uses and which financial year it covers. Then the accounts it touches, each with a number and a name. Then the vouchers: one #VER per document, with its series, number and date, and inside it a #TRANS row per posting — account, amount, date, text. Records end with a carriage return and a line feed, not with a bare newline.

Type matters. A 4E file is a whole financial year with opening and closing balances; a 4I file is the transactions of a period. This module writes 4I and refuses to write 4E, and the refusal is not a gap in the implementation. It keeps the sales ledger and nothing else — it books no wages, no purchases and nothing to the bank account — so it cannot state a balance, and a 4E file without balances claims a completeness it does not have.

The invoices in the file are issued documents only, dated by the date printed on them rather than by the row's creation timestamp. An invoice written on 2 October carrying 30 September is a September document, and the whole point of putting a date on a page is that it, and not the clock, decides the period. The file the accountant gets walks through one.

SIE4 is written in CP437, the original IBM PC code page. Not UTF-8, not Latin-1, not "whatever the editor saved".

This is the single most common defect in the format and it looks cosmetic until you see it. Write the file as UTF-8 and every å, ä and ö arrives as two characters of rubbish. Björkgården becomes BjörkgÃ¥rden. What it corrupts is not a label in our software — it is the customer's own name, the account names, the text on every voucher, in somebody else's books.

The header row that declares the encoding is #FORMAT PC8, PC8 being the format's name for code page 437. It is a line that tells the importing software how to read every character below it, and it is a lie unless the bytes really were converted. So the conversion happens explicitly, once, at the very end, after the whole file has been assembled as text.

Two consequences follow. CP437 has no ł and no €, and a strict conversion answers an unmappable character by producing nothing at all — one Polish surname in a customer list would turn a month's export into no file. So the conversion transliterates instead: an approximation is imperfect and visible on the page, whereas an empty export is neither. And the file is never returned inside a JSON response, because JSON is UTF-8 by definition and serialising the bytes would undo the one thing the exporter exists to get right. The export is fetched as a stored file.

SIE is also the only thing this module produces that it never reads back. Everything else can be repaired by somebody who understands the system; a SIE file is opened by somebody who does not, and what they see when it is wrong is a line number and a refusal.

BAS is the chart of accounts almost every Swedish company starts from — and almost every one of them then changes. So these are the defaults, used when nothing on the line says otherwise:

• 3001, 3002, 3003 — Försäljning inom Sverige at 25, 12 and 6 per cent moms.
• 2611, 2621, 2631 — Utgående moms on those same three rates.
• 1510 — Kundfordringar. What the customer owes.
• 1513 — Kundfordringar, delad faktura. The half of a ROT or RUT invoice that Skatteverket settles, kept off 1510 so an ageing report cannot chase the state as though it were a customer.
• 3740 — Öres- och kronutjämning, which takes the öresavrundning row.

Sales are split by rate because BAS splits them, and because the split is a check: the revenue account and the VAT account of one line are meant to be verifiable against each other, and 12 per cent revenue posted to the 25 per cent account breaks that check quietly.

They are defaults and not truths. A line's own account code wins, and that code is pinned onto the line at the moment the line is written rather than read from the article catalogue when the export runs. That distinction is worth a sentence: reading the catalogue at export time meant that remapping an article in June moved the accounts of documents that had already been exported in March. A zero-rated line gets no default at all, because the right account depends on why it is zero-rated — an export, a reverse charge and an exempt supply are three different accounts, and only the company can say which. It is booked to the standard sales account and a warning says so, rather than being guessed at silently. A BAS chart for a service company covers the accounts around these.

Double entry means the amounts in one voucher sum to zero. An accounting package refuses an entire import over a single voucher that does not, and it reports it as a line number to somebody who has no way to fix it.

So the check happens here instead, and it is strict in a specific way: the sum is taken in öre, over integers, before anything is formatted. The same check on printed kronor would pass a voucher that is one hundredth out — which is precisely the size of the error a rounding mistake makes, and precisely the one an importer catches. If a voucher does not sum to zero, no file is written at all. Not a file with a warning attached; no file. The message names the invoice and the difference, in front of the person who can still do something about it.

Three more refusals sit beside it, all of the same shape. An invoice in a currency other than SEK is refused rather than posted, because a ledger kept in kronor cannot take an amount in euro without the rate it was converted at, and nothing in the module records one — booking 1 000 EUR as 1 000 SEK would be silent. Drafts and cancelled documents never reach the file, because a draft has no number and may never be sent, and exporting one books revenue nobody has been billed for. And a line charging VAT at a rate with no Swedish account to post it to stops the export rather than landing somewhere plausible.

The export also tells you what it assumed. A missing organisationsnummer is a warning rather than an invention: an absent #ORGNR is a question the accountant asks, while a made-up one imports cleanly into the wrong company and nobody finds out until the year is closed.

A SIE file declares one financial year in its #RAR row, and every voucher inside it has to fall within that year.

The default is the calendar year, because that is the räkenskapsår most Swedish companies keep. A company on a brutet räkenskapsår — May to April, say, or September to August — sets the starting month in its own settings, and #RAR follows it. Without that, a company on a May-to-April year would be handed a file whose declared year contradicts every voucher inside it, and the import would fail at the far end for a reason nobody there could diagnose.

A period that spans two financial years is refused rather than quietly clipped or quietly mislabelled. It is nearly always a mistyped month, and when it is not, it is two exports. Refusing costs somebody thirty seconds; clipping costs a reconciliation.

Dates are compared as dates against a date column, never taken through a timestamp. Converting either side to a timestamp moves the boundary by the offset between Stockholm and UTC, and drops the last invoice of a month into the next one for every export run after midnight.

Before the file is written you can see what it would contain: how many invoices, how many postings, which accounts are touched, the first and last vouchers, every warning, and — the point of the whole screen — what has already been exported for the same dates. Somebody about to export September sees that September went out on the 3rd before they send a second file, rather than after the month has been booked twice.

A second export is allowed, because a corrected file is an ordinary request. It is never silent. The file that goes out is written to storage and kept rather than regenerated on demand, because regenerating produces a different file the moment anything behind it has changed, and the entire value of the record is that it says what was actually handed over.

What this does not do is worth stating plainly, because it is the question a buyer should ask. It is not bookkeeping. There is no general ledger, no voucher series outside sales, no purchase ledger, no wages, no year-end close, no annual report and no VAT return filed to Skatteverket. It replaces the cost of invoicing software, not the accountant — and the honest pitch is that it hands your accountant a clean SIE4 file instead of a stack of PDFs to retype, which usually lowers the fee without removing it.

And one thing we will not claim. The export is written to the format and balance-checked before a single byte is produced, but it has not been round-tripped through a live Fortnox installation. We will not write "validated with Fortnox" until somebody has actually imported a file into one. If you want to test that before you commit, take a month's export to your accountant and have them try it — that is the right order to find out in.