Swedish invoicing that knows VAT per line, splits ROT and RUT on the labour but never on the materials, never leaves a hole in the number series, and hands clean SIE4 to the accountant.
From 139 kr/month
Replaces Fortnox Fakturering
14 days free, per module. No card.
What that means in practice
An issued invoice cannot be changed through any of the five doors that reach it. The correction is a credit note, never an edit — which is what the Bookkeeping Act actually requires.
The number is taken when the invoice is sent, not when the draft is created, and inside the same transaction that renders and stores the PDF. If anything fails afterwards, the number goes back.
ROT at 30 and RUT at 50 per cent are computed on the labour including VAT. The line type decides, not a tick box — a cable somebody flagged as eligible still cannot carry a deduction.
The invoice is copied from a note
The hours are in one system, the materials on a piece of paper and the price in somebody's head. What is not found is not billed, and it shows only when the year is totted up.
ROT and RUT are done by hand
The deduction is computed on the wrong base, or put on a materials line. That is not a slip but an incorrect claim to the tax authority, and it surfaces long after the customer has paid their share.
The accountant gets a PDF
Somebody types the same figures a second time, into another system, against another chart of accounts. Two entries of one amount are two chances for them to disagree.
This is an invoicing and receivables module. It does not keep a general ledger — see the limits further down, they matter.
Twenty-five, twelve, six or zero on every line. The invoice shows what was charged at each rate separately, because one blended figure cannot be declared. Öresavrundning is its own entry, so the lines really do add up to the total beneath them.
Labour and materials on separate lines, the deduction on labour including VAT, and a deduction line carrying a negative amount. The buyer's personnummer — stored encrypted, shown masked — and the fastighetsbeteckning, or the housing cooperative's organisation number and the apartment number, are required before the invoice is sent and printed on it. The customer pays their share, the rest is a claim on the state — and it posts to its own account so the ageing report does not chase the tax authority as though it were a customer.
The counter is a row locked while the number is drawn, not a database sequence — a sequence survives a rollback and would leave a permanent hole. The number is taken inside the same transaction that creates the invoice, so a failure after the allocation gives the number back.
The invoice is rendered once, stored, and served from then on — never re-rendered. A template edited next spring cannot rewrite last autumn's invoices. If the file is missing the system answers with an error rather than quietly handing back something that resembles it.
An OCR reference with a Luhn check digit, statement import in CAMT.053 and CSV, and matching at three levels — where only the safest posts without a person looking. A payment already registered by hand is not booked a second time when the statement arrives. Reminders at three levels, with the statutory fees.
SIE4 against the BAS chart of accounts, plus export onwards. The account is pinned on the line when the line is created, so an article remapped in June does not rewrite the March export — the same month exported twice gives the same file.
From a completed job, or built by hand from customers and articles.
VAT per rate is visible before you send. The number is taken only now, and the PDF is stored.
OCR on the invoice, the statement imported, the matcher proposing or posting.
SIE4 for the period, balanced per voucher, to whoever keeps the books.
For paid ROT and RUT invoices Closepact builds Skatteverket's claim file. You import it in Skatteverket's e-service and sign with BankID, and the decision is booked when it comes.
Built for Swedish rules
This is the part of the product that cannot be built generically and localised afterwards.
Tiers
The same tiers the billing code charges for. The price below is what the module costs alone; from the second module 15 per cent comes off, from the third 25.
139 kr/month
3 users included, then 29 kr/user
279 kr/month
5 users included, then 39 kr/user
449 kr/month
10 users included, then 49 kr/user
Being activated: built and part of the tier at the price shown, but not yet switched on. It waits on agreements and accounts on Closepact's side, not on more development, and until then the app shows it as unavailable.
Planned, not delivered. It is listed so the tier is honest about where it is going — but none of it is part of what you pay for today.
Together, and apart
With the scheduling module, approved hours, materials and ROT/RUT become a draft invoice with no export. With the proposals module the customer is already in the register, and if you invoice without scheduling, an accepted quote becomes an invoice draft on its own (proposals Väx or Pro).
On its own the invoice is built by hand from customers and articles, with the same VAT, the same deduction, the same series and the same SIE4. The basis view sits empty with a link to the scheduling module — not as a block, but as what it is.
Honest about the edges
This is here because it is cheaper to read now than to discover after the contract is signed.
This is not bookkeeping. No general ledger, no voucher series outside sales, no year-end close, no annual report and no VAT return to the tax authority. The module replaces the cost of the invoicing software — not the accountant.
The annual ROT and RUT ceiling per person is not applied, and the document says so. The ceiling depends on what every other company claimed for the same buyer that year, which this system cannot see. An amount capped without that data is wrong in exactly the way nobody checks.
The SIE4 file is balance-checked by us but not yet trial-imported into a live Fortnox. We will not say "validated with Fortnox" until it is.
E-invoicing over Peppol does not exist yet. It needs a certified access point and is marked "planned".
Closepact does not send the ROT/RUT claim to Skatteverket itself. Skatteverket has no API for it, so somebody at your company imports the file Closepact builds into the e-service and signs it with BankID. Part payments, credited invoices and corrections are handled in the e-service by hand.
Autogiro, a supplier ledger, inventory and a fixed-asset register are not included, and are not planned.
Common questions
No. Straight answer: the module invoices and runs the receivables ledger, but it keeps no books, does no year-end close and files no VAT return. What it does is give your accountant a clean SIE4 file instead of a stack of PDFs to retype — which usually lowers the fee without removing it. Anyone saying otherwise is selling.
For the parts that concern customer invoicing, yes. The number series is unbroken because the number is drawn under a row lock and handed back if anything fails afterwards. An issued invoice cannot be changed through any route — not the invoice, not the lines, not the ordering, not deletion — and the correction is always a credit note. The PDF is rendered once and stored, so the document you show in seven years is the document the customer got.
As a file you import. Skatteverket takes the request for payment only through its e-service Rot och rut – företag, signed with BankID, and offers no API for it. Closepact lists the paid ROT and RUT invoices that are ready to claim, and what is missing on the rest, then builds Skatteverket's import file — schema version 6, checked against Skatteverket's XSD — one per deduction type and payment year, with up to 100 buyers each. You import it in the e-service and sign. Skatteverket's decision, approved, partly approved or rejected, is recorded by hand or read from its decision file and booked: what was paid against the tax account, what was refused back onto the customer's balance.
Not yet. It requires a certified access point on the Peppol network and is marked as planned. The Peppol id field exists on the customer, but nothing is transmitted — and the API says so plainly rather than pretending it went out.
Yes, and that is the ordinary case. You invoice here and export SIE4 to Fortnox for the period. The account is pinned on the invoice line when the line is created, so the same month exported twice gives the same file — an article remapped in June does not rewrite the March export.
Yes, from CSV. Semicolons or commas, Swedish or English column headers, and quoted descriptions spanning several lines held together instead of becoming two articles. An article number that is too long is refused with a message rather than truncated — two articles truncated to the same number otherwise become one, and the survivor carries the other's price.
Matching works at three levels and only the safest posts by itself: an OCR reference that passes Luhn and resolves to exactly one open invoice. An invoice number in the message field, or a unique outstanding amount, becomes a proposal for a person to approve. Of the two mistakes automatic posting can make, reminding the customer who did pay is the one that costs the relationship.
Yes. A recurring invoice is set to every so many weeks, months, quarters or years, on a day of the month, and with automatic sending on it is issued and emailed by itself. If it cannot go — no email address, no ROT/RUT buyer, a refused email — it stays a draft with the reason written on it, and everyone allowed to send invoices is emailed.
Twenty minutes, no slides. We set the module up with one of your own cases before the call.