Myntos, accounting for Norway with the source in the open
Myntos is a Norwegian regnskapsprogram built at Lindeman Technologies. Double-entry bookkeeping on the SAF-T Financial data model from day one, invoicing checked against bokføringsforskriften before anything is issued, and the whole program public for anyone to read. It is pre-alpha, and the page says so.
Why build another accounting program
The rules are already public. Bokføringsloven states what has to be recorded, Skatteetaten publishes the formats, and the MVA-melding is an open specification. The program that sits between a business and the state translates one public document into another, and there is no good reason for that translation to be a black box. So the source is public: you can read what happens to your numbers, and run it yourself if you would rather.
The second reason is the data model. Most bookkeeping software grows a schema organically and then bolts a SAF-T exporter onto the side years later, which is where the export inconsistencies come from. Myntos starts from the SAF-T Financial model and treats the export as a projection of what is already stored, not a translation layer written under deadline.
What works today
- Accounts and organisations: email or Google sign-in, colleagues invited into an organisation with roles, and a subscription that attaches to the organisation rather than to a person. Invitations are one-time links, stored hashed.
- Cash-flow register: money in and out, where the category decides both the account and the VAT code, with the gross-to-net split, immediate posting, and corrections made by reversal rather than by edit.
- Invoicing: a salgsdokument is validated against bokføringsforskriften § 5-1 before it can be issued, with every finding naming the paragraph it comes from. Numbering is gapless by construction: a draft has no number, so discarding one leaves no hole. Issued invoices are corrected only by kreditnota.
- E-invoicing: the EHF / Peppol BIS Billing 3.0 document is generated and frozen at issue, ahead of the 2027 requirement. Transmission is not built yet, since that needs a Peppol access point.
- Voucher archive: PDFs attached to a posted bilag, append-only, validated by magic number, with a digest stored alongside.
- Invoice reading: upload the PDF first and the date, amount, VAT, invoice number and counterparty are read out of the text layer, with the category picked from a numbered menu by a small model hosted in Norway on Løynd. It is optional, off without a key, and nothing posts until the user confirms.
What is not built yet
Myntos is pre-alpha and the roadmap is public for the same reason the source is. The SAF-T Financial export, the automatic MVA-melding, the skattemelding and næringsspesifikasjon submissions through Skatteetaten's sluttbrukersystem APIs, and machine filing of the årsregnskap to Regnskapsregisteret through Altinn 3 are all designed and interfaced but not finished. Maskinporten covers the retrieval side; submission legally requires an ID-porten login, which shapes how the auth flow has to be built.
Where the data lives
Books and identity documents are the part of a business that cannot be casually handed to whichever region a cloud provider defaults to. PostgreSQL runs in an EEA region, document storage for bilag is Cloudflare R2 with the EU jurisdiction set, and the storage rules are written down in the architecture docs rather than left as an implementation detail. The invoice-reading model is the case that would normally leak a document abroad, which is exactly why it runs on our own hardware in Norway instead of a foreign API.
Stack
- Frontend: Astro and TypeScript on Cloudflare Workers.
- Backend: Python 3.12, FastAPI and SQLAlchemy, containerised for Cloudflare Containers in the EU jurisdiction.
- Database: PostgreSQL in an EEA region, migrations through Alembic.
- Domain layer: ledger, bilag, faktura, MVA and identity kept separate from the HTTP surface, with the SAF-T export and the government integrations as their own modules.