Invoicing in Sweden: what the law asks for.

A Swedish invoice is not a letter with an amount at the bottom. It is a document somebody else's bookkeeper has to be able to tick off against what Skatteverket requires, and most of what is on it is a requirement rather than a layout choice.

The document this module renders states, in order: seller and buyer by name and address, the seller's organisationsnummer and momsregistreringsnummer, the buyer's where they are known, the invoice number, the invoice date, the due date, the delivery date (the date of supply) where it differs from the invoice date, the payment terms in days, and the customer number. Then every line — description, quantity, unit, unit price, discount, VAT rate, amount. Then VAT summarised per rate, öresavrundning as its own figure whenever it is not zero, the total, and the payment reference. Where the seller is approved for F-tax the document says "Godkänd för F-skatt", because that sentence is what tells the buyer they do not have to withhold tax on the labour.

Two smaller decisions follow from the same reasoning. The document is written in Swedish even when the rest of the product is used in English, because its reader is not a user of the software but the customer's bookkeeper — "Moms" and "Öresavrundning" are the names of the requirements, not translations of them, and an invoice headed "VAT summary" is one they have to translate back before they can tick it off. And anything the organisation has not filled in is left off rather than printed as an empty label. "Org.nr:" followed by nothing reads as a fault in the software rather than a blank in a settings screen.

Sweden charges four rates and the module accepts four: 25, 12, 6 and 0 per cent. Anything else is refused where it is typed, because a 24 that slips through produces an invoice that is wrong in the way nobody notices for a quarter.

The rate belongs to the line, not to the document. An invoice with materials at 25 per cent and transport at 6 owes two figures to Skatteverket, and the invoice prints both — rate, base, VAT — in a summary of its own. A single blended rate cannot be declared however correctly it adds up, so the module never computes one. The per-rate summary is also pinned to the invoice at the moment it is issued rather than rebuilt when somebody opens the document years later: how rates are bucketed is a rule in code, and a statutory figure should not depend on which version of that rule happens to be deployed.

Three rules sit underneath. The discount comes off before VAT, because VAT is owed on what was actually charged and not on a list price the customer never paid. Every amount is an integer number of öre and no float ever touches money. And rounding happens exactly once per line, with the totals being sums of rounded lines rather than roundings of exact sums — the two differ by a few öre on a long invoice, and only one of them has the property a customer will actually check, which is that the lines printed on the page add up to the figure printed under them.

Öresavrundning gets a row of its own. Two and a half hours at 645 kr is 1 612,50 net, 403,13 in moms and 2 015,63 gross; the document rounds to 2 016,00 and prints the 37 öre rather than folding it into the total. Half rounds away from zero in both directions, so a credit of 100,50 is refunded as 101 rather than quietly as 100. Why the rate has to sit on the line goes through the declaration side of it.

Bokföringslagen expects the invoice numbers a company issues to form an unbroken series. The obvious implementation — count the invoices, add one — satisfies neither half of that. Two requests count the same total and both claim the same number, and deleting a row makes the next one a duplicate.

So the counter is a row of its own, and taking a number means locking that row, reading it and writing it back inside one transaction. Two people sending different invoices in the same second queue behind each other for a few hundred milliseconds instead of racing. That is the right way round: sending is not a hot path, and an unbroken series is a legal requirement while throughput here is a preference.

Where the number is drawn matters as much as how. It is drawn inside the same transaction that renders and stores the PDF, never before it. Allocate outside and the first failed render leaves a hole — the counter has moved, no document carries what it moved past, and a year later nobody can say what the missing number was for. Allocating inside is only safe because the counter is a table row and not a database sequence: a sequence survives a rollback, which is exactly what makes sequences unusable here. A row does not, so a rollback hands the number back and the next caller gets it.

What that buys is a series with nothing to explain. A draft never takes a number, so abandoning one costs nothing. A second click on Send does not take a second number; it is answered with a 409 naming the invoice that already exists. And invoices and credit notes count on separate counters in separate series, because both start at 1 — leaving credit notes in the invoice series makes the first correction anybody raises collide with invoice number 1. The number series, in full.

The default is 30 days. The terms are copied onto the invoice from the customer when the draft is made and read off the invoice when it is issued — never read from the customer record again at that moment, because that would silently move the due date of a document whose terms were agreed weeks ago by somebody editing a customer in between.

The invoice date is taken in Swedish time rather than the application's UTC. For the two hours after midnight every summer a UTC date is yesterday's, and on the first of a month that files the document in the previous VAT period, to be discovered by whoever reconciles the return rather than by anybody in the office.

Dröjsmålsränta ships with no default at all, and that is a decision rather than an omission. Räntelagen § 6 puts it at Riksbank's referensränta plus eight percentage points, and the referensränta is reset twice a year. A rate written into a configuration file would be wrong within six months, and it would be wrong on a document the customer is entitled to dispute. An organisation that has not configured a rate charges no interest, which is the only answer that cannot be wrong. A rate agreed in a contract with one customer beats the house setting, because that is what was signed.

When interest is charged it is computed on what is outstanding, over the days actually late, divided over 365, and it carries no VAT — interest is compensation for a late payment and not a supply of anything, and moms on it is an error the customer's accountant would find. The amount is stored on the reminder that went out rather than recomputed on read, so somebody disputing a charge is shown the figure that was on their letter instead of a different one for every day since.

The fees follow the statutory ceilings — 60 kronor for a påminnelse and 180 for an inkassokrav under förordning (1981:1057) — and the first level carries none by default, because a first reminder arriving with a charge on it reads as a penalty for a slow bank transfer. Terms, interest and what they cost.

The OCR reference is the invoice number with a check digit on the end, and the check digit is the entire point. The bank refuses a mistyped reference at the moment of payment rather than a fortnight later, and a payment whose reference checks out can be matched to an invoice by a machine instead of by somebody reading a statement.

Two variants exist and the bank decides which. Soft is the number plus a Luhn check digit. Hard inserts a length digit before it, so the bank can also refuse a reference that is the right digits in the wrong quantity — a digit dropped from the middle passes Luhn about one time in ten, and length control catches most of the rest. Twenty-five digits is the ceiling either way. Longer than that and the payment is refused at the bank, which is the worst failure available here: the customer wanted to pay and could not.

Luhn is the same algorithm as on a card number, so it is worth saying what it does not do. It catches every single-digit error and almost every transposition of two adjacent digits. It is not a signature. A reference that checks out was probably typed correctly; it is not certainly ours.

A credit note deliberately carries no reference at all. Nothing is ever paid into our account against one. Giving it a reference would be actively harmful rather than merely useless: the two series count independently, so credit note 1 and invoice 1 reduce to the same digits and therefore to the same OCR, and a payment arriving with it would find two documents and no way to choose between them. OCR references and bankgiro covers the bank end of it.

A draft is a working document: no number, editable, and thrown away for nothing. An issued invoice is the opposite of all three. It has been read by somebody outside the company, it carries a number from a series that has to be unbroken, and it has to be reproducible exactly as sent for seven years.

So there is no route from issued back to draft and there never will be one. The status machine has no such transition, and one editable check is the single guard every write in the module goes through — the invoice, its lines, their ordering, deletion. The PDF is part of the same promise: it is rendered once at issue, stored on a private disk with a SHA-256 checksum beside it, and served from then on rather than re-rendered. A template edited next spring cannot rewrite last autumn's documents, because last autumn's documents are files and not a rendering of today's template.

A mistake is answered with a second document that points at the first, takes its own number from its own series, and has the sign turned round. Both sit in the books and the pair nets to what was actually owed. The credit note is issued immediately rather than parked as a draft, because a correction that exists only for us is one the customer cannot see while the original is still being chased at its full amount. The original is untouched except for its status, and even that only when the whole of it has been credited — a part-credited invoice is still outstanding for the remainder, and marking it credited would quietly take money the company is still owed off the ageing report.

Four shapes of credit exist because all four happen: the whole invoice, one line of six, part of a quantity, or an agreed amount with no line behind it at all. The last of those states its VAT rate rather than inferring one, because an invoice with materials at 25 per cent and transport at 6 has no single rate to infer, and guessing declares the wrong figure for the period. Reminders, collection and what may be charged picks up what happens when the corrected invoice still is not paid.