ROT and RUT, computed correctly.

ROT and RUT change who pays, not what the work costs. The invoice is written at the full amount; the customer transfers part of it and the company claims the rest from Skatteverket.

The rates are 30 per cent for ROT and 50 for RUT, and both are computed on the labour including VAT. That last part is the one most often got wrong, and getting it wrong is not neutral: computing on the net understates every deduction by a fifth, and nobody ever rings up to complain that their invoice was too large.

Because the invoice is settled by two parties, a ROT document has to show both figures. The summary gives the total, then the deduction as a negative row, then what the customer actually transfers. A document showing only the total is one neither party can check — the customer cannot see why the amount at the bottom is smaller than the lines above, and the bookkeeper cannot see where the difference went.

On the invoice the deduction is a generated line, always last, under the work it was computed from. It is written by the system rather than by a person, because a ROT line somebody can edit is a claim to Skatteverket that disagrees with the invoice it sits on, and the disagreement surfaces as a rejected claim months later. Try to type one and the API refuses it with a sentence saying so.

A deductible job still buys materials, and a customer entitled to RUT is not entitled to it on the cable. So the deduction has a base, and the base is the labour.

The mechanism matters more than the rule. A line qualifies only if it is both labour and flagged eligible, and whether it is labour is a property of the line's type, not of a setting somebody can change per line. The types a person may write are goods, service, labour, travel and fee; only labour and service are work. Flag a box of cable as eligible and it still cannot carry a deduction, because the type says goods and the type is what the calculation reads.

That is the difference between a tick box and a category, and it is the whole argument. A tick box on a materials line is two individually correct facts — "this is cable", "this customer has RUT" — assembling themselves into an unlawful claim. Nobody in the office made a decision that was obviously wrong; the system let two right answers add up to one wrong one. Excluding by type means the wrong claim cannot be constructed in the first place.

The same reasoning runs one level up, into the article register. Whether an article may carry a deduction is answered by the article itself rather than by a second list of qualifying types kept beside it. Two lists drift apart, and the half that drifts wrong is the one that puts ROT on cable.

And the deduction line carries a VAT rate of zero rather than the rate of the work it reduces. It is not a sale. Giving it a rate would drop it into a bucket in the per-rate summary and understate a figure that gets declared.

ROT — a bathroom.

• Labour, 40 hours at 650 kr: 26 000 kr net, 6 500 kr moms, 32 500 kr including VAT.
• Materials: 18 400 kr net, 4 600 kr moms, 23 000 kr including VAT.
• The invoice: 44 400 kr net, 11 100 kr moms, 55 500 kr in total.
• ROT: 30 per cent of 32 500 = 9 750 kr.
• The customer transfers 45 750 kr. The remaining 9 750 kr is claimed from Skatteverket.

Two ways to get that wrong, both of which produce a number that looks perfectly reasonable on the page:

• 30 per cent of the invoice total is 16 650 kr. That is an over-claim of 6 900 kr. Skatteverket refuses it months later and the customer is then asked for money they thought was settled.
• 30 per cent of the labour excluding VAT is 7 800 kr. That is a fifth less than the customer is entitled to. It is the version that never generates a complaint, which is exactly why it survives in spreadsheets for years.

RUT — a cleaning visit.

• Six hours at 520 kr: 3 120 kr net, 780 kr moms, 3 900 kr including VAT. All of it labour.
• RUT: 50 per cent of 3 900 = 1 950 kr.
• The customer transfers 1 950 kr, and 1 950 kr is claimed.

The line that appears on the document reads "RUT-avdrag, 50 % av arbetskostnad inkl. moms", with the amount negative, the VAT rate zero, and the base it was computed from stated beside it. How the ROT calculation runs end to end works through a longer job; RUT for a cleaning company does the recurring case.

A ROT invoice has one total and two debtors. The posting reflects that: the customer's share goes to 1510 Kundfordringar and the state's share to 1513, which BAS keeps as a separate receivable for exactly this.

The reason is the ageing report. What a customer owes is the invoice total, less the requested deduction, less what they have paid. The household in the example above who transferred 45 750 kr owes nothing at all. A ledger that put the whole 55 500 kr on 1510 shows them 9 750 kr in arrears, and sooner or later somebody sends a reminder for it — to a customer who has paid everything they were asked for. The module refuses that reminder in words rather than silently: nothing is outstanding from the customer on this invoice.

The claim itself is genuinely outstanding, just not from a household, so the report states it beside the buckets instead of inside them — split into what is still with Skatteverket and what Skatteverket has refused. A refused claim is money the customer owes again, and the invoice does not know it yet because nothing has re-invoiced it; it is reported there because otherwise it is reported nowhere.

One more exclusion carries a statutory figure. The deduction line is left out of the VAT summary entirely. ROT does not reduce the VAT the company owes the state — Skatteverket settles that part separately — so folding a negative line into a rate bucket would understate what gets declared for the period.

There is an annual ceiling per person on what ROT and RUT are worth to a buyer. This module does not apply it, and cannot.

The reason is not effort. The ceiling is consumed by every company that has claimed for that person during the year — the roofer in March, the cleaner every second Thursday since — and none of that is visible from inside one company's invoicing system. A figure capped without that data is wrong in the way that is hardest to catch: it looks like a careful number. Somebody would have to already know the right answer to notice it was the wrong one.

So the invoice says so, in print, under the deduction: the annual ceiling per person has not been checked on this invoice, it depends on what every provider has claimed for you during the year, and if Skatteverket refuses all or part of the request we will invoice the difference. That last sentence is the one worth putting in front of a customer at the time rather than in a phone call four months later.

A share is the related case, and it is refused rather than approximated. Two owners of a property claim half each, and a draft invoice built automatically from a scheduled job that carries a partial share will not be generated: the deduction on an invoice is computed at the statutory rate on the whole of the eligible labour, and claiming the full rate where half was agreed is an over-claim. The refusal happens while somebody is still looking at the job, and that invoice gets written by hand.

The calculation is built, and so is the claim file. The submission itself stays with you. It is worth being exact about which is which.

What exists today: the split between labour and materials, the rate, the base including VAT, the generated deduction line on the invoice, the receivable posted to 1513, the claim record with its own status and its own settled and refused amounts, and the buyer's details, entered in the panel on the customer: the personal number, and either the property designation (fastighetsbeteckning) or, for a bostadsrätt, the housing association's organisationsnummer and the apartment number, plus a co-applicant and a share where there is one. The personal number is validated when it is entered, stored encrypted and shown masked; the full number is shown only through a reveal that is written to the audit log, because a table of Swedish personal numbers is a liability a table of invoices is not. An invoice with a deduction cannot be sent until those details are in place, and they are printed on it, together with the split between labour and materials and the address where the work was done.

The claim file: from paid ROT and RUT invoices the module builds Skatteverket's import file — XML in Skatteverket's schema version 6, validated against Skatteverket's XSD — one file per deduction type and payment year, at most 100 buyers per file. It lists which invoices are ready to claim and what is missing on the rest, and flags the 31 January deadline in the year after payment. Skatteverket's work types (Bygg, El, VVS, Städning and the rest) are set per invoice and per line. When the decision comes — approved, partly approved or rejected — it is recorded by hand or read from Skatteverket's decision file, and booked: what is paid to 1630 against 1513, what is refused back to 1510 against 1513 because the customer owes it again, and öre that cannot be claimed to 3740.

What does not happen here: sending the request. Skatteverket has no API for it, so the company imports the file in the e-service Rot och rut – företag and signs the request there with BankID; Closepact sends nothing to Skatteverket itself. Part payments and credited invoices are still filed by hand, and the annual ceiling above is still not applied.

We would rather write that sentence here than let somebody find it out in week three. The alternative version of this page would say "ROT and RUT, automated", and the first customer to reach the filing step would discover it means something narrower than it sounded.