Overview of which Norwegian laws, standards and industry conventions Macct enforces automatically. Written for auditors, bookkeepers, the Norwegian Tax Administration — or anyone who wants to verify what the system actually does. The statuses implemented, partial and missing reflect the actual code on the master branch.
| Rule | Requirement | In Macct |
|---|
| § 4 nr. 1 |
Debit = credit on every voucher |
Hard-validated in the bookkeeping service. Unbalanced vouchers are rejected with a clear error message. |
| § 5 |
Voucher requirements: date, description, counterparty, amount |
Validated via DTO validation and the service layer. |
| § 9 |
Chart of accounts |
NS 4102 with 260+ accounts pre-populated. |
| § 10 |
Traceability — recorded data must be traceable both from documentation to reporting and the other way |
Implemented. Vouchers are recorded with opprettet_av_bruker_id + timestamp, exchange rates have a documented source, voucher numbers are monotonic per company, and all material events (login, IDOR attempts, sanity discrepancies, approvals) are written to an immutable audit log. |
| § 10 |
Tracking changes to master data (customers, suppliers, payroll, user permissions) |
Implemented via an audit trigger in the storage layer. Every change is stored with a before/after snapshot (JSON) plus who and when. |
| § 11 |
Specifications: general ledger, customer sub-ledger, supplier sub-ledger |
Implemented as reports, with a daily sanity job that verifies the general ledger and the sub-ledgers match exactly. |
| § 13 |
Retention 5 years |
Implemented. Vouchers are immutable after creation, regardless of whether the period is open or closed. Modification and deletion are blocked at the storage layer. Corrections are made through reversal entries. |
| § 14 |
Correction via reversal, not deletion |
Implemented for vouchers — reversal creates a counter-voucher with debit/credit swapped, the original is kept unchanged, and double reversal is blocked. Partial for invoices — once sent, the invoice is immutable, and the posting can be reversed via a reversal voucher. A dedicated credit-note flow with its own invoice number is on the roadmap. |
| Rule | Requirement | In Macct |
|---|
| § 1-6 |
Small entity (after 1 Nov 2024): turnover ≤ NOK 168M, total assets ≤ NOK 84M, ≤ 50 FTEs. At most one threshold may be exceeded for two years in a row. |
Checked in Nrs8Validator (all three conditions). Macct is primarily designed for entities below these thresholds. |
| § 4-1 |
Fundamental principles: accrual, matching, prudence (lowest value), consistency |
Built in. Revenue is recognised on invoicing (not payment), depreciation matches cost over useful life, open foreign-currency receivables are revalued at year-end. |
| § 4-3 |
Congruence principle — results must flow through the income statement, not directly against equity |
Hard-validated. Direct postings to 2050/2070/2080 are blocked, except for opening entries, year-end closing and reversals. |
| § 4-9 |
Translation of foreign-currency items at the balance-sheet-date rate |
Implemented in year-end closing. Open receivables and payables are revalued at the 31 Dec rate; the unrealised difference is posted to 8060 (gain) or 8160 (loss) with full audit trail. |
| § 5-2 |
Fixed assets are capitalised and depreciated |
Soft warning for amounts > NOK 30,000 on accounts 6500-6599 (cf. Tax Act § 14-40). The depreciation schedule is manual. |
| Simplification/requirement | How in Macct |
|---|
| Simplified note requirements (8 mandatory notes) |
Generated in the annual accounts via AarsregnskapService. |
| No cash-flow statement required |
Omitted — we do not generate this for the small-entity flow. |
| Entertainment — deduction limit NOK 592 per person (2026, Tax Payment Regulation § 6-46-1) |
Soft warning on account 7330 (Entertainment) when the amount exceeds NOK 592. The user gets an explanation and is referred to 7350 (gifts, non-deductible) for the excess. |
| Prudence for receivables — lowest value |
Partial via year-end revaluation. Manual assessment of bad-debt risk per customer is not automated. |
| Audit obligation — can be opted out if turnover < NOK 7M + assets < NOK 27M + < 10 FTEs (Companies Act § 7-6) |
Checked in Nrs8Validator — shows the status and refers to the Register of Business Enterprises for the actual opt-out. |
| Rule | Requirement | How in Macct |
|---|
| § 14-40 |
Capitalisation threshold NOK 30,000 excl. VAT for fixed assets |
Soft warning for amounts > NOK 30,000 on accounts 6500-6599 (tools, fixtures, operating equipment, software) — where the WorldCom pattern typically arises. The user is referred to 12xx capitalisation. For foreign-currency vouchers the amount is shown in both NOK and the original currency. |
| § 14-41 |
Declining-balance depreciation, groups A-J with fixed rates (10–30 %) |
Not automated — must be entered manually with the correct rate per group. |
| § 6-1 |
Deductions in business activity |
Implemented via NS 4102 posting. The posting suggestion points to the right deduction account based on text analysis. |
|
Corporate tax 22 % (AS, 2026) |
Posted in year-end closing on account 8300 (Tax expense) → 2500 (Tax payable) for AS. |
| Rule | Requirement | How in Macct |
|---|
| § 2-1 |
Registration obligation — turnover > NOK 50,000 in the past 12 months |
Setting — the company is marked VAT-liable via selskap_innstillinger. There is no automatic monitoring of the threshold. |
|
VAT rates: 25 % (high), 15 % (food), 12 % (low, transport/culture), 0 % (export/exempt) |
All rates as SAF-T codes (3, 31, 33, 5, 52, 6, 1, 11, 13, 14...). VAT is auto-calculated per line. |
|
Bi-monthly return (6 terms/year) |
Implemented via /api/rapport/mva and posting to account 2740 (settlement account). |
|
Term lock after the VAT return is filed |
Implemented — regnskapsperiode.mva_lukket is set when the VAT settlement is posted. Subsequent VAT vouchers in the term are blocked. |
|
SAF-T v1.30 (mandatory from Jan 2025) |
Export via SaftExportService. |
|
Account / VAT-code consistency |
Hard-validated — 1610-1619 must use an inbound VAT code, 27xx (except 2740) must use an outbound code, 3xxx allows only outbound, 4xxx-7xxx allows only inbound. |
| Component | In Macct |
|---|
| Account classes 1-8 (assets, equity+liabilities, sales revenue, cost of goods, payroll, depreciation, operating, finance+tax) |
260+ accounts pre-populated and enforced. |
| Sub-ledger accounts 1500 (customer) / 2400 (supplier) require per-partner specification |
Hard-validated — lines on 1500/2400 without a partner are rejected both in the bookkeeping service and at the storage layer. |
| VAT clearing accounts 1610-1619 / 27xx |
Built in — used for automatic VAT posting. |
| Rule/requirement | In Macct |
|---|
| General ledger in NOK |
Built in — bilagslinje.debet/kredit is always in NOK; converted via formula at write time. |
| Daily rate from Norges Bank |
Auto — @Scheduled cron 17:30 UTC on weekdays; lastNObservations=30 (~6 weeks of history). |
| Rate source must be documented for manual overrides (Bookkeeping Act § 7) |
Hard-validated — when the user overrides the auto-fetched rate, an explicit source text is required (e.g. "DNB exchange note no. X-12345"). Auto-fetched rates are tagged "Norges Bank YYYY-MM-DD". |
| Realised currency difference at payment |
Auto-posted to 8040 (currency gain) or 8150 (currency loss) when the payment rate differs from the invoice rate. |
| Unrealised currency difference at 31 Dec (Accounting Act § 4-9) |
Implemented at year-end. Open receivables and payables are revalued at the balance-sheet-date rate; the difference is posted to 8060 (gain) or 8160 (loss). |
| 4 fields per accounting line: valutakode, valutakurs, belop_valuta, belop_nok |
NOT NULL on bilagslinje, faktura, fakturalinje, faktura_betaling. Default NOK / 1.0 / amount / amount. |
| Conversion factor (1 vs 100 for JPY/HUF/KRW) |
On the currency master — valuta.antall_per_kurs. Formula: belop_nok = belop_valuta * valutakurs / antall_per_kurs. |
| Layer | Mechanism |
|---|
| User interface |
Inline validation and soft warnings. The user gets explanatory messages pointing to the correct posting. |
| Business logic |
Hard validation: balance requirement, partner requirement for customer/supplier receivables, locked periods, VAT-code direction, congruence principle, rate source, and that the invoice date is within a reasonable interval. |
| Storage |
Built-in rules in the data layer enforce the same invariants as the business logic: partner requirement on 1500/2400, one currency per voucher, immutability in closed periods, and monotonic voucher numbers per company. |
| Daily reconciliation |
Sub-ledger sanity (01:15 UTC / 02:15 local): verifies that the sum of customer receivables and supplier payables per partner matches the balance in the general ledger. Currency reconciliation (01:30 UTC / 02:30 local): verifies that the formula belop_nok = belop_valuta × rate / conversion factor holds across all posted rows. Discrepancies > NOK 0.01 are reported to firmapost@macct.no. |
For a small entity within the NRS 8 framework, Macct covers the essentials. The following is deliberately not automated or out of scope:
