← All posts
Bookkeeping

The SIE4 file your accountant opens, and the two ways it usually arrives broken

SIE4 is CP437, not UTF-8, and one voucher that does not balance makes an accounting package refuse the whole file. Two vouchers worked out in full, including a ROT invoice.

The Closepact team10 min read

TL;DR

SIE is the only thing an invoicing module produces that it never reads back. Everything else can be repaired by somebody who understands the system; a SIE file is opened in Fortnox or Visma or BL Administration by somebody who does not, and what they see when it is wrong is a line number and a refusal. Two defects account for almost all of those refusals, and both are closed before the file is written rather than discovered at the other end.

4I, not 4E, and why that is an honest answer

SIE type 4E is a whole financial year with opening and closing balances. Type 4I is the transactions of a period.

An invoicing module keeps the sales ledger and nothing else. It has never seen a salary, a purchase or a bank account, so it cannot state a balance — and a 4E file without balances claims a completeness it does not have. 4I is exactly what we do know.

If your accountant asks for 4E, the answer is that they should be producing it from the books they keep, using this file as one of its inputs.

Defect one: the character set

SIE4 is CP437 — the original IBM PC code page — and not UTF-8. A file written as UTF-8 imports with every å, ä and ö turned into two characters of rubbish. It is the most common defect in the format, it looks cosmetic, and what it corrupts is the customer's own name.

The header row #FORMAT PC8 is the format's way of naming code page 437. It is the line that tells the importer how to read every å below it, and it is a lie unless the bytes have actually been converted.

There is a wrinkle worth naming. CP437 has no ł and no €. A bare conversion answers an unmappable character by failing outright, so one Polish surname in a customer list would turn a month's export into no file at all. So the conversion transliterates: an imperfect approximation, visible on the page, where the alternative is an empty export nobody can explain.

Records end with CRLF rather than a newline, which is a second small thing that breaks quietly.

Defect two: a voucher that does not balance

Double entry means the amounts of one voucher sum to zero. An accounting package refuses the entire file over a single voucher that does not.

So the check is made here, in front of the person who can still fix it, and if it fails no file is written at all. The sum is taken in öre, over integers, before anything is formatted — the same check on the printed kronor would pass a voucher that is a hundredth out, which is precisely the size of the error a rounding mistake makes and precisely the one an importer reports as a line number.

Voucher one, worked

The three-rate conference invoice from VAT per line: 52 393,00 kr total, with öresavrundning of −0,20.

AccountNameAmount
1510Kundfordringar+52 393,00
3001Försäljning inom Sverige, 25 % moms−24 000,00
3002Försäljning inom Sverige, 12 % moms−11 760,00
3003Försäljning inom Sverige, 6 % moms−8 700,00
2611Utgående moms, 25 %−6 000,00
2621Utgående moms, 12 %−1 411,20
2631Utgående moms, 6 %−522,00
3740Öres- och kronutjämning+0,20

Sum: 0,00. A debit is a positive amount and a credit a negative one, which is how SIE writes them.

Voucher two: a ROT invoice

The bathroom job from How ROT is actually calculated: 66 613,00 kr total, 12 615,00 kr claimed from Skatteverket, öresavrundning of +0,50.

AccountNameAmount
1510Kundfordringar+53 998,00
1513Kundfordringar – delad faktura+12 615,00
3001Försäljning inom Sverige, 25 % moms−53 290,00
2611Utgående moms, 25 %−13 322,50
3740Öres- och kronutjämning−0,50

Sum: 0,00.

Two things to notice. The receivable is split — the customer's half on 1510 and the state's half on 1513 — so an ageing report built on this ledger does not chase Skatteverket as though it were a customer. And the deduction is not booked as negative revenue: doing that would understate the turnover of every company that does ROT work, and understate the VAT they owe along with it.

What the file looks like

#FLAGGA 0
#PROGRAM "Closepact" "1.0"
#FORMAT PC8
#SIETYP 4
#GEN 20260401
#FNAMN "Nordkust Event AB"
#ORGNR 556123-4567
#RAR 0 20260101 20261231
#KONTO 1510 "Kundfordringar"
#KONTO 2611 "Utgående moms på försäljning inom Sverige, 25 %"
#VER "A" "1043" 20260318 "Faktura A-1043 Vikbolandets Konferens AB" 20260401
{
#TRANS 1510 {} 52393.00 20260318 "Vikbolandets Konferens AB"
#TRANS 3001 {} -24000.00 20260318 "Vikbolandets Konferens AB"
}

(The company and its organisation number are invented.) A few of those rows are load-bearing:

#FLAGGA 0 says the file has not already been taken into somebody's books. A 1 would claim it had, and is for a re-export of a file the receiver has already read.

#ORGNR is how the receiving software decides whose books these are. If the organisation has not recorded one, the export carries no #ORGNR and says so in a warning — an absent number is a question the accountant asks, while an invented one imports cleanly into the wrong company and nobody finds out until the year is closed.

#TRANS carries empty braces for the object list, and they are not optional: a #TRANS without them is a malformed record even when nothing in the system uses cost centres.

Amounts use a decimal point, whatever a Swedish keyboard does. Every amount upstream is an integer of öre, and this is the last thing that happens to it.

#RAR declares one year

A SIE file declares one financial year and every voucher in it has to fall inside that year, so a window spanning two 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.

The calendar year is the default because that is the räkenskapsår most Swedish companies keep. A company on a brutet räkenskapsår — May to April, say — sets the starting month in its own settings, and #RAR follows it.

What goes in, and what does not

Issued documents only. A draft is not an invoice: it has no number, it may never be sent, and exporting one books revenue nobody has been billed for.

Dated by issue date, not by when the row was created. An invoice written on 2 October carrying 30 September is a September document, and the whole point of the date on the page is that it, and not the clock, decides the period.

Kronor only. An invoice in euro is refused, because a ledger kept in kronor cannot be handed a foreign amount without the rate it was converted at, and nothing in this module records one. Refusing is loud and fixable; booking 1 000 EUR as 1 000 SEK is neither.

The same month twice gives the same file. The account is pinned onto the invoice line when the line is written, so an article remapped in June does not rewrite March's export.

Names with quotation marks in them

A customer called Bygg "Bosse" AB is not hypothetical, and the quote and the backslash are the two characters that can end a SIE field early. Both are escaped. Control characters are replaced rather than escaped, because the format has no escape for them and a newline inside a field ends the record and shifts everything after it by one line.

What we do not claim

The file is balance-checked by us. It has not been trial-imported into a live Fortnox installation, and we will not write "validated with Fortnox" until it has been. That is a specific claim with a specific test behind it, and we have not run the test.

SIE export sits in the Väx and Pro tiers of the invoicing module.

Further reading

Keep reading

Want to see this with your own jobs?

Book a 20-minute demo. We set up one of your own jobs before the call: a quote, a week on the schedule or an invoice.

Book a demo