Documentation you'd actually want to read.
Getting started, the data model, writer mechanics, funder library conventions, ledger reconciliation, and how reports are generated. Plain English, Finnish-civic-specific examples.
Getting started
A new workspace usually begins with one operator, one organisation profile, and the first three active grants. The intended first hour is simple: verify the organisation, choose a plan, add the grants already in motion, and bring in the person who carries the budget or reporting context.
Nordbrief is designed so the first meaningful value appears before any integration is connected. You can begin with manual grant entries and a draft in the Writer, then connect PRH, Procountor, bank exports, and SSO afterwards. The product should become useful in sequence, not only after a week of setup.
Data model
The core model is deliberately small: Organisation, Workspace, Grant, Draft, Ledger line, and Report. The organisation owns durable memory such as voice, governance notes, prior applications, and operating facts. The workspace is the active operational surface for the people currently doing the work.
A grant is the spine that connects writing, deadlines, reporting, and money. Drafts hang off the grant; ledger lines can be linked back to the same grant or report; generated reports are snapshots rather than separate systems of record. The point is to avoid duplicated truth across Word, spreadsheets, and report portals.
Writer mechanics
The Writer is a two-column editorial surface. The left side holds the actual draft; the right side carries organisational memory, evaluation criteria, prior context, and next-step guidance. AI assistance is intentionally constrained: it helps extend, critique, cite, and compress, but every AI-assisted paragraph is marked with provenance rather than silently blended in.
The intended workflow is editorial rather than chat-based. You stay inside the document, revise sentence by sentence, and treat assistance as insertable material that still needs judgement. The Writer therefore privileges continuity, tone, and traceability over novelty or volume.
Funder library
The funder library is structured around real Finnish and Nordic application work: deadlines, grant types, likely focus areas, language preferences, and reporting expectations. A funder record is not just a name and a URL; it is a compact memory of how that funder tends to read, decide, and ask follow-up questions.
A 'focus match' is not a black-box score pretending certainty. It is a legible signal derived from your organisation profile, recent grant history, and the funder's published scope. Missing funders can be added progressively, and a manually-added funder should behave like a first-class record rather than a temporary exception.
Ledger and reconciliation
Ledger work starts from the same reality organisations already live in: Procountor exports, bank CSVs, receipts, and line-by-line category decisions. Nordbrief does not try to replace accounting software; it creates the reporting-facing layer that ties financial movement back to the grant and the narrative it supports.
Reconciliation status matters because report writing and budget checking are rarely separate tasks in practice. A line that is still open should remain visible as open in the report-preparation flow. A line that has been matched to source material should not need to be re-explained each time a funder asks for an update.
Reports
Reports are generated from the same operational record rather than rebuilt at the end of the project. Narrative sections draw from the grant draft and organisation memory; financial sections draw from reconciled ledger categories and report notes. The aim is not auto-generated perfection but a coherent first draft with fewer copy-paste errors.
Different funders expect different shapes: STEA, municipal grants, foundations, and EU programmes all ask the same underlying questions through different templates. Nordbrief keeps the shared underlying data stable and adapts the output layer to the template instead of forcing teams to maintain separate reporting universes.
Organisation memory
Organisation memory is where voice, governance, recurring facts, and prior application knowledge live. It is the layer that normally disappears when a project worker leaves or when a board changes and nobody wants to reopen five years of scattered folders to remember how something used to be phrased.
The purpose is not archival completeness. It is operational reuse: phrases your organisation stands behind, statistics you cite repeatedly, governance decisions that affect future applications, and previous asks that still shape today’s positioning. Memory is only useful if it surfaces at the point of writing.
Billing and plan changes
Plans are intentionally simple: choose the operating tier that matches the organisation’s scale, then add seats as the working team grows. Seat changes should be visible immediately in Settings, reflected on the next invoice, and never require support just to handle a normal quarter’s staffing rhythm.
Legal and billing operations stay close to the product. DPA acknowledgement, data export, plan changes, invoice history, and cancellation are all product-level concerns because small organisations should not need a separate procurement workflow for ordinary software administration.