When Skatteetaten asks for a SAF-T Financial file, the clock starts. Norwegian bookkeeping rules require accounting data in the standard SAF-T Financial XML structure — a header identifying the reporting entity, a master-files block covering general ledger accounts, customers, suppliers, tax codes and analysis dimensions, and a GeneralLedgerEntries block carrying every journal line for the requested period. ERPNext already holds all of that data, but it holds it as GL Entry, Account, Customer, Supplier, Sales Taxes and Charges Template and Accounting Dimension records — not as the Norwegian standard account grouping and MVA tax-code structure the schema expects. Finance teams end up exporting to spreadsheets, hand-mapping the chart of accounts, hand-building XML, and discovering the mismatch only when the file is rejected.

ERPNext core stops well short of this. It has no SAF-T schema awareness, nowhere to persist a mapping from your Account tree to the Norwegian standard accounts, no MVA tax-code mapping table, no XML serialiser, no XSD validator, and no record of what was sent and when. Accounting Dimensions can carry the analysis data, but nothing translates them into the Analysis structure of the file. Every request becomes a manual project, and any correction after a rejection means starting again from a spreadsheet nobody trusts.

ECOSIRE builds this as a proper Frappe app installed on your bench — its own module, its own DocTypes, its own permissions, no patched core files. A Norway SAF-T Settings single DocType holds the reporting entity, the target file version and the sender registration details. Mapping DocTypes hold the account-to-standard-account and tax-template-to-MVA-code relationships, with a validate hook that refuses submission on an incomplete mapping so gaps surface before an export rather than after. A SAF-T Export DocType is the working record: choose company and date range, submit, and a background job enqueued via frappe.enqueue streams GL Entry rows in batches, assembles the master-files and general-ledger-entries blocks, and writes the XML as a File attached to the export. The same posting is rendered twice — machine XML for Skatteetaten and a human-readable print format on the same document — so your controller reviews exactly what the authority receives. Every generated file is validated against the official XSD before the export can be marked ready, with a line-level error report naming the offending voucher instead of an XML byte offset. Whitelisted methods expose generation and status over the Frappe REST API, hooks.py doc events on Account, Customer, Supplier and the tax templates flag newly created records as unmapped at creation time, and an optional scheduler event pre-validates the open period nightly so the file is already known-good when the request arrives.

Rejection handling is a first-class workflow. A rejected submission is recorded against the export with the authority's reason, and a correction export can be raised that references the original, re-runs against the amended ledger, and preserves both versions. Nothing is overwritten: every generated file, its validation result, its submitter and its timestamp stay attached to an immutable record with the standard Frappe document trail, and role profiles separate who may configure mappings, who may generate, and who may confirm a submission.

This is build-to-order. There is no instant download — ECOSIRE builds the app for your ERPNext instance, against your chart of accounts, your MVA setup and your Frappe/ERPNext version (v15 or v16), on your own bench or a Frappe Cloud private bench. Delivery starts with a scoping call, moves to a fixed written scope, then build, UAT on a staging copy of your own data, and go-live with a documented rollback plan and a post-go-live support window. Typical delivery is one working week from confirmed scope. You receive the full source and the git repository, so the app is yours to keep, audit and extend.