TL;DR
Payment terms are a number of days on the invoice, defaulting to thirty. Dröjsmålsränta under räntelagen § 6 is the Riksbank's referensränta plus eight percentage points. The referensränta is reset twice a year, so 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. So no default rate ships at all. An organisation that has not configured one charges no interest, which is the only answer that cannot be wrong.
Terms live on the document, not on the customer
Thirty days is the default, and it is a default rather than a rule: terms are commercial and negotiable, and plenty of Swedish B2B relationships run on ten, fifteen or sixty.
What matters more than the number is where it is read from. The terms are copied onto the invoice when the draft is made, from the customer record as it stood that day. At issue, the due date is computed from the invoice's own terms — not by reading the customer again.
The reason is a failure that is invisible when it happens. Somebody edits a customer record in June to change standard terms from 30 days to 15. If the due date were computed by reading the customer at issue time, every draft written in May and sent in June would silently acquire a due date two weeks earlier than the one that was agreed. Nobody would see it. The first sign would be a reminder going to a customer who is not late.
What räntelagen actually says
Räntelagen § 6 puts dröjsmålsränta at the referensränta plus eight percentage points, from the due date. The referensränta is set by the Riksbank and reset twice a year.
We do not print a rate on this page, and the product does not ship one. Both for the same reason: any number written down here is wrong from the next reset, and unlike most stale marketing copy this one would end up on a document a customer can dispute. What the system does instead is leave the rate empty until somebody sets it, and charge nothing until they do.
Worked: what the interest actually comes to
Interest is a rate and a number of days producing an amount, which is the same shape as a quantity and a unit price producing one — so it goes through the same arithmetic, with the same single rounding to öre.
Suppose an invoice with 24 500,00 kr outstanding, 21 days past due, and a rate of 10,00 per cent that you entered yourself in settings. (That rate is an illustration. It is not a rate this product ships, and it is not advice about what yours should be.)
24 500,00 × 0,10 × 21 / 365 = 140,96 kr
Three things about that line:
- The denominator is 365. Räntelagen counts actual days, so the year is 365 days and the count is from the due date to today, not a month-based approximation.
- VAT is zero. Interest is compensation for a late payment, not a supply of anything. Charging moms on it is an error a customer's accountant notices and that you cannot defend.
- It rounds once. 14 095,89 öre becomes 14 096 öre, and that integer is what is stored.
The figure is written down, never recomputed
A customer who rings up about a late fee is entitled to the figure that was on the letter they were sent. A system that recomputes it from a percentage and a date answers with a different number every day that passes, and the one day it matters is the day somebody disputes it.
So what gets stored on a reminder is the amount charged, not the rate it came from: the fee in öre, the interest in öre, the rate as it stood, the outstanding balance on that day, and the number of days overdue. A payment arriving tomorrow changes what is outstanding; it must not change what the letter said.
A customer's own terms beat the house default
Where a rate has been agreed with a specific customer, that rate is used. Where it has not, the organisation's default applies. That order is the only one that matches what was signed — a contract with one customer is not overridden by a settings screen somebody changed last month.
The invoice footer follows the same logic. It prints the interest sentence only when that customer's account actually carries a rate. No rate, no sentence: a document that threatens interest the company has not configured is a promise it will not keep, and an invoice is a bad place to bluff.
What "outstanding" means on a ROT invoice
This is the subtlety that catches most receivables systems.
What a customer owes is not the total on the invoice. It is the total, less the part claimed from Skatteverket, less what has already been paid. A ROT job invoiced at 66 613,00 kr with 12 615,00 kr claimed as a deduction leaves 53 998,00 kr outstanding from the customer, and not a krona more.
When that 53 998,00 arrives, the invoice is settled as far as the customer is concerned. The remaining 12 615,00 is a claim on the state, it sits on its own account in the books, and chasing the customer for it is both useless and — to somebody who has paid everything asked of them — insulting. So the reminder policy refuses it outright, with a sentence rather than a code: nothing is outstanding from the customer on this invoice.
When an invoice becomes overdue
Overdue is asked rather than stored, because it becomes true by a day passing and nothing else: the due date is behind us, the status still expects money, and something is genuinely outstanding. A scheduled job writes the status down so lists can be sorted by it, but the computation above is the truth that job records.
Days overdue is zero rather than negative for an invoice that is not yet due. "Minus twelve days overdue" is not a thing anybody wants to read in a column of them, least of all in an ageing report.
Part payments, and what "paid" means
A balance that drifts from the receipts behind it is the other way a receivables ledger goes quietly wrong, and it goes wrong in two specific ways.
Two payments in the same second. Both read the same old balance and both write their own amount over it. The one that lost is not visible anywhere: the receipt row is there, the total is wrong by exactly that amount, and the customer who paid twice gets a reminder. So the invoice row is locked first and every figure is read again under that lock.
Incrementing rather than re-deriving. Adding each payment to a running total is right until something is deleted, corrected or replayed, and then it is permanently wrong with no way to notice. So the paid figure is summed from the payment rows every time. It is the same arithmetic and it cannot drift from them.
Three refusals sit alongside. A payment of nothing is not a payment. A payment in a different currency from the invoice is not a payment against that invoice — converting here would mean inventing a rate, and the rate on the day the money left is the bank's business. And a refund is money that actually moved, so it belongs on the invoice as a negative payment rather than as the erasure of the receipt it refunds; deleting a receipt is only for a receipt that should never have been written at all.
When a receipt that came from a bank statement is deleted, the statement line goes back into the review queue in the same transaction. A payment deleted while its line still reads "matched" is money the bank says arrived and the system says is accounted for, with nothing left showing either — and the line has dropped out of the only list anybody reviews.
Where interest meets reminders
Interest accrues on its own. A reminder is a separate decision, with its own fees, its own grace period and its own limits on what a schedule may do without a person. Reminders, collection notices and what you may actually charge covers the fees — including why the first reminder deliberately carries none.