Custom public financial management software
Public money is allocated money. A representative body or board adopts a budget, which sets a ceiling per programme within which spending is allowed. Spending outside that decision is not a minor setback; it is a question of authority that resurfaces in the annual accounts. Appfront builds custom software for that chain: drawing up and amending the budget, recording commitments at the moment of award, cash and liquidity management, and a trail from annual accounts line to source document that an auditor can follow.
Public money works differently from business money
In a business, a budget is an expectation. Management sets it, and if revenue rises the department may spend more than planned, because profit is the real measure. In a public administration, a budget is a decision. The amount allocated to each programme has been authorised by a council, a board or an elected body, and that amount is both the ceiling and the mandate. Spending more first requires a change to that decision, and only then a payment. This is known as budgetary authority, and it is why PFM software looks different from financial software for a business: the central question is not how much is earned, but whether every pound has been spent within a valid decision and whether that can be demonstrated afterwards.
A second difference lies in when money is committed. A business that tracks its costs by invoice date has a workable picture. A public organisation does not, because a whole financial year can pass between the award of a contract and the first invoice. As long as that award is recorded nowhere, the budget appears free when it has in fact already been spent. The commitments ledger is therefore not an accounting side issue but the core of the system, and the reason budget holders in the public sector work with three figures rather than two: budgeted, committed and actual.
This applies wherever money with a public purpose is managed, not only at a municipality or province. Water boards, implementing agencies, joint arrangements and partnerships face the same questions, often in a more complicated form, because they account to several participants, each with their own budget cycle. Institutions in education, care and culture that are largely funded from public money work on the same logic: they have their own operations, but must account for earmarked funds separately for each scheme. And public funds and programme bureaus see the problem from both sides, as they are both recipient and grantor. What all these organisations have in common is that the test is not return, but whether the money was spent on the purpose for which it was made available.
Are you in the right place? This page is about public money: budgetary discipline, commitments in advance and accountability afterwards. If you are looking for analysis of business figures, such as margin by product or customer, variance analysis on results or consolidation of a group, then this is about financial analysis in a business and not this subject. If your question is mainly about reconciling bank transactions, sub-ledgers and the general ledger, you want financial reconciliation software. Here the central question is whether an expense fell within an established decision.
The budget is a ceiling
The amount approved for each programme is the upper limit. The system should show what remains available, not only what has been booked.
The commitment comes before the invoice
Money is committed at the moment of award, even if nothing has been paid yet. Without recording that, the budget holder steers on an outdated picture.
Accountability is the end product
The annual accounts are not an internal report but the document on which a board is judged and on which the auditor issues an opinion.
Building the budget, and keeping it balanced
A public budget is built in rounds. There is a starting point with the existing multi-year series, a set of assumptions on wage and price developments, and a number of proposals for new policy that are not yet in that series. Service departments submit their figures, the finance function adds them up, and then the cutting and shifting begins until the whole balances. In most organisations this process consists of a series of spreadsheets circulated by email each round, with the result that at the end nobody can precisely reconstruct which version led to the final decision.
Software only helps here if it models the process itself and doesn't just store the end result. That means: a budget round as an object with an owner and a status, proposals that exist as separate amendments with supporting rationale beneath them, and a scenario in which a board can see what happens if a proposal is dropped or postponed. Multi-year planning is not an extra here: public budgets routinely look several years ahead, and a proposal that costs almost nothing in the first year can upset the whole series in the last. Anyone who only sees the first year is making decisions with half the information.
Who may do what is already a question at the design stage. A budget is adopted at a high level but executed by budget holders, each managing a part, sometimes with sub-allocations to deputy budget holders per team or project. That division is not an administrative detail: it determines who may commit spending, up to what amount, and who may approve an invoice. In many organisations this division lives in a decision that sits outside the system, so the authorisations in the software and the formal mandate gradually drift apart. Software that treats budget holdership as a first-class concept, with a validity period and a designated substitute during absence, keeps the two aligned and makes after-the-fact control considerably simpler.
Investments also need separate treatment alongside the operating budget. A credit is often made available in one go for a project running over several years, whereas the budget is set year by year. You therefore monitor two ceilings at once: the total credit over the project's lifetime, and the portion that may be spent in the current year. In addition, part of the project costs is capitalised and returns in later years as depreciation in the operating budget, while another part lands directly as an expense. A system that treats credits as an ordinary budget line almost always gives an incomplete picture: it shows utilisation of the annual amount without the position of the credit, or exactly the reverse.
At the same time, the structure of the budget must match the structure in which it is later accounted for. For Dutch local and regional governments, the Besluit begroting en verantwoording prescribes a fixed framework: the budget and the annual accounts follow the same structure of programmes and task areas, with mandatory explanations and a number of fixed sections on topics such as business operations, resilience and the maintenance of capital assets. Internationally, the IPSAS standards play a comparable role for public sector reporting. We do not cite article numbers here, because those shift; what remains is the requirement that the structure of your budget, your general ledger and your annual statements can be mapped onto one another. If you build software without making that mapping explicit, the bill arrives at year end, when a posting to a cost centre can no longer be traced back to the programme on which the council decided.
Changing the budget without losing the original position
Once the year is under way, the budget changes. A task is added, a government grant comes in differently, a project shifts, a reserve is drawn upon. Each of these cases requires a decision, and that decision should leave a trail: which proposal, which amounts, which year, who was authorised to approve it, and on what date. What goes wrong in practice is that the new position overwrites the old one. Afterwards no one can show what was originally adopted, and that is precisely the figure an organisation is held to account against.
The workable solution is to treat the budget as a layered whole: the baseline set at the start stays untouched, every change is a separate mutation layer with its own characteristics, and the current position is the sum of these. This allows a report to show three columns at once: approved at the start, after changes, and actual. Authority matters here too. A shift within a single programme is often an officer's competence, whereas a shift between programmes or an increase to a ceiling is not. Software that understands this difference can process the first kind quickly and block the second until a decision has been made, rather than sending everything through the same heavy procedure.
The commitment is the link that ties all of this to reality. The moment a contract is awarded, the full amount should be recorded in the system as a commitment, spread across the years in which the service is delivered. On receipt and approval, part of that commitment is released and a cost entry appears. What remains is a residual commitment, which is deliberately reviewed at year-end: does it carry over to next year, or is it released? This review is one of the few points where an organisation truly gains control over old, forgotten obligations. If your procurement process is still separate from your financial administration, it starts with custom procurement software, because a commitment that only arises when the invoice arrives is one you can no longer steer.
On the invoicing side, a great deal will change in the coming years: e-invoicing under the European standard and reporting per transaction rather than per tax return. What this demands is covered in ViDA software.
What PFM software must be able to do
These six components cannot be separated. A budget without commitments gives an overly rosy picture, commitments without a liquidity forecast say nothing about when the money will actually leave, and everything together is useless if the trail to the source document is missing.
Multi-year budget structure
Rounds, proposals and scenarios in the same structure as the annual accounts, with all years of the series displayed side by side.
Changes as a separate layer
The position at the start remains in place; each change is a separate mutation with its decision and date; the current position is the sum.
Commitments administration
The award records the full amount, spread across years. Receipt releases a portion; the remainder is assessed at year-end.
Cash management and liquidity forecasting
Outstanding commitments, granted contributions and investment planning converted into expected cash flows per period.
Annual accounts and interim reporting
Progress reports and the annual accounts drawn from the same source, with explanatory notes and periodic information supplied to third parties.
Audit trail per entry
From annual accounts line to entry to source document, recording who approved it and when, without overwriting.
Cash management and liquidity in a public administration
Treasury in a company seeks returns within a risk framework. In a public organisation the mandate is narrower and stricter: the money must be there at the moment a commitment has to be paid, with as little risk as possible. Holding surpluses and investing them at one's own discretion is not a free choice for Dutch decentralised governments, as funds not immediately needed are parked with the national treasury. On the borrowing side there are also limits. In practice an organisation works with a cap on the amount of short-term borrowing, the cash-credit limit (kasgeldlimiet), and with a norm that limits how much of the long-term debt may be renegotiated within a single year, the interest-rate risk norm (renterisiconorm). We do not state amounts or percentages here, as these differ by organisation type and by year; what you should expect from software is that these limits are held as parameters in the system and that you can see where you stand before taking out a loan.
A usable cash flow forecast in the public sector does not come from historical cash movements, but from decisions that have already been taken. Outstanding commitments know when they fall due. Grants and contributions awarded come with advance payment rhythms and conditions. Investment projects have a schedule that shows when instalments are due. On the income side, much is fixed in a periodic cycle of central government contributions and in the assessment cycle of your own levies. Set these four sources side by side and you get a forecast that can be explained month by month and adjusted when a project slips. If you manage grant flows as the awarding party, this aligns with custom grant software, where decision, condition and advance payment belong together.
Cash management also includes a loan administration, and in the public sector this is rarely internal alone. Alongside your own borrowings, there are often on-lent loans to affiliated entities and guarantees issued to third parties. The latter two do not appear as expenditure in the budget, yet they represent a risk that must be explained in the accountability and that can suddenly cost money at the wrong moment. Software that only tracks your own debt misses half the picture. What you want to record per loan and per guarantee is the counterparty, the term, the repayment schedule, the security and the maturity date, with a signal before anything falls due.
On the purchasing side, the invoice flow should support this. An incoming invoice should be matched automatically to an existing commitment, so the approver only has to confirm that the service was delivered and does not need to work out again which budget it belongs to. Where suppliers invoice electronically, in the Netherlands usually via the Peppol network or in a structured message format, that link can largely run without manual effort. That matters: with a manual flow, the delay almost always occurs between receipt and reaching the right approver, and that delay costs a public organisation both statutory payment terms and goodwill with smaller suppliers. More important for this topic, every invoice booked outside the commitment creates a gap in the picture your budget holders steer by.
The payment process itself is where most errors are prevented or made. Segregation of duties is not a formality here: the person who creates a supplier or changes a bank account must not also be able to release the payment. A change to a bank account number should trigger its own approval step, as that is the route through which payment fraud enters. And because a payment batch in the public sector is rarely ticked off by one person alone, the system must also be able to show who in the chain has seen what.
- Budgeted, committed and realised side by side per budget holder
- Forecast built from decisions, not from historical averages
- Treasury ceiling and interest rate risk norm as parameters, not as loose memos
- Advance payment and settlement of contributions in the same administration
- Segregation of duties between creditor management and payment release
- Change of a bank account with its own approval step
- Outstanding commitments at year end assessed deliberately
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →From budget to annual accounts and regularity
On paper the chain is simple: an approved budget, a commitment, a delivered service, an invoice, a payment, a posting in the general ledger and ultimately a line in the annual accounts. In practice that chain almost always breaks at the same point: coding. The council decides at programme level, the service departments work with projects, finance posts to cost centres and general ledger accounts, and external reporting requires a breakdown by policy area. If these four classifications are not linked in one place, the same manual work repeats every year: a spreadsheet that maps postings to programmes, created by one person, with no trace of the choices made along the way.
Software resolves this by defining the coding once and deriving everything else from it. A posting then carries not only a ledger account but, in the same record, the programme, the service area and, where relevant, the project. Reporting becomes a matter of aggregating rather than recalculating, and interim reporting draws from the same source as the annual accounts. That is not just more efficient; it is the only way to ensure that interim reports and the year-end statements do not contradict one another.
The chain depends even more on the month-end close. Creditors, debtors, fixed assets, loans and payroll are subledgers, each with its own total, and that total should reconcile to the general ledger. If it does not, the difference is pushed into a suspense account, and suspense accounts are where problems remain invisible for months. What you should expect from software is that it shows this reconciliation itself, period by period, with the open differences listed, rather than someone checking it by hand in a spreadsheet each quarter. This is also where an audit most quickly gets stuck: an unexplained suspense balance takes more investigation than all other findings combined.
In addition, public sector financial reporting involves several matters that business software rarely handles well. Investments are capitalised and depreciated over several years, with a distinction between investments with and without economic utility that affects coverage. Reserves and provisions are not free pots of money; each has a decision and a purpose, and movements in them should appear as a separate, visible line rather than as an adjustment against a programme. Contributions received with an obligation to spend are not income until the service has been delivered, and therefore belong on the balance sheet. And the allocation of overheads requires an explicit method, because the outcome per programme shapes the picture on which accountability is judged. These are precisely the areas where a home-built system either adds value or becomes a problem: the logic can be made explainable, but someone must have deliberately designed it.
Between the budget and the annual accounts lies the year itself, and that is the period in which course correction is still possible. An interim report that only compares actuals against budget signals too late, because part of the year is, by definition, not yet booked. What works is a forecast per budget: actuals to date, plus open commitments, plus the budget holder's own estimate of the remainder of the year. That third element is subjective, which is precisely why the system should record who gave the estimate and when. In this way, a variance becomes a conversation about an expectation rather than a surprise at year-end close, and it immediately provides the justification for the budget revision that usually follows.
Two further requirements apply in the public sector and are often overlooked in a design. The first is separate accountability for earmarked funds: money that comes from another government body for a specific purpose must usually be accounted for under the terms of each scheme, with its own definitions and reporting dates that do not match your programme structure. That means a posting must be linkable to a scheme as well as to a programme and policy area, because filtering afterwards on a description in the document does not work. The second is access. In social services and implementing agencies, payments relate to individuals, and financial data is therefore also personal data. Roles, traceability of who views what, and a retention period for each type of data belong in the design, not in the handover.
Lawfulness is the question that comes on top of that, and it does not exist in a business. Not: did we book it correctly, but: was this expenditure permitted? That breaks down into a few verifiable questions. Did the amount fall within a valid, adopted budget? Was the order placed in line with your own procurement rules and, above the applicable thresholds, under the procurement regime? Were the conditions of a scheme from which it was paid, or to which the recipient was granted funding, complied with? Was the service delivered and confirmed by the right person? Where a board itself issues a statement on financial lawfulness with the annual accounts, that question stops being a closing item and becomes a requirement on how your processes are set up, and therefore on your software.
The trail an auditor must be able to follow
An audit almost always starts with a figure in the annual accounts and works downwards. The question is therefore not whether your system produces attractive reports, but whether someone can go from a total, via a selection, to the individual postings, and from a posting to the document and the approval behind it. If that cannot be done in the system, it happens by email, and then the availability of your staff determines how long the audit takes.
What is needed is limited and concrete. Postings cannot be edited, only corrected, so the original entry remains alongside the correction. Every approval records who approved it, when, and on the basis of which authority, and that record sits in a log that cannot be rewritten, even by an administrator. Documents are attached to the posting rather than stored in a network folder, and commitments, invoices, proof of performance and payments are linked to one another. For a sample, the auditor must be able to draw and export a selection independently, without anyone pre-selecting the items. Findings, follow-up and their status should also have a place, as they form the bridge between two audit years. If oversight is your core question, then custom audit software is the broader subject; here, the audit trail is a property of the financial administration itself.
When an off-the-shelf package is the better choice
Public finance is not an empty corner of the software market. There are mature financial packages designed specifically for municipalities, provinces, water boards and implementing agencies, with the prescribed structure of programmes and policy areas built in, commitment accounting as a standard feature, and vendors who update their product when reporting rules change. For some readers of this page, that is the wiser route, and we would rather say so now than halfway through a conversation about custom development.
If your household follows the usual pattern of budget, amendment, commitment, realisation and annual accounts, you can buy that off the shelf, including the upkeep of those rules. Your effort shifts from building to configuring and keeping your own coding structure clean, which is work you should have been doing anyway.
Custom development pays off in fewer situations than vendors suggest, but a few come up again and again. The first is the layer around the general ledger: an environment where budget holders, project leads and policy staff see their own position, request changes and record commitments without needing to understand the financial package. This is where an organisation saves the most time, and it is exactly the part packages tend to handle least well. The second is your own calculation rule: an allocation model, an apportionment scheme or a coverage methodology that follows from your own policy and does not fit a standard form. The third is integration with line-of-business applications, because figures on levies, benefits, permits or property arise outside the financial administration and need to flow in without manual work.
Two practical points often matter more than functionality in the decision. The first is the transition itself: you do not start from zero, but from an opening balance, outstanding commitments, credits that are halfway through their term, and a history you still have to account for. How many years you bring across, and in what form, is a choice that must be made early, as it determines a large share of the work. The second is that a public organisation usually has to procure the system through a tender. The requirements you write then determine the result: if you specify features that packages already have, you will receive packages, and if you describe only the problem, you will receive bids that are not comparable. The trade-off between package and custom build therefore needs to happen before the tender, not after it.
The downside should be stated honestly too. If you build your own, keeping up with changing reporting and accountability rules falls to your organisation, and that is recurring work, not a one-off cost. That is why a middle course is often the best answer: a package for the administrative core and general ledger, custom development for the portal, the integrations and your own calculation rules, with a documented boundary between the two. You can read how we approach that trade-off under an ERP system built to measure.
- Package when your household follows the usual pattern
- Package when you want to outsource the upkeep of rule changes
- Custom development for the layer where budget holders work themselves
- Custom development for your own allocation, coverage or apportionment model
- Custom development for integrations with your line-of-business applications
- Middle path: package as the ledger, custom development at the front
Frequently asked questions about PFM software
In a business, a budget is an expectation and the result is the yardstick: margin per product or customer, variance on the result, consolidation across a group. In a public household, the budget is a decision with a ceiling per programme, and the question is whether every expenditure fell within a valid decision. Two things follow that business software rarely handles well: money is committed at the moment of award rather than at the invoice, and accountability afterwards must be traceable for each posting back to a source document and an approval.
Because there can be a long gap between awarding a contract and receiving the first invoice. If that commitment isn't recorded anywhere, the budget looks free when it is already spent, and that discrepancy only comes to light when there is nothing left to send. With a commitments ledger, a budget holder works with three figures side by side: budgeted, committed and realised. When the service is received, part of the commitment is released and the cost posting appears. Whatever remains open at year-end is assessed deliberately: carried forward to next year or released.
Yes, and it is a design decision you need to make upfront. The workable approach is a layered budget: the position established at the outset remains untouched, every change is a separate adjustment referencing the decision, the amounts per year and the date, and the current position is the sum of those layers. A report can then show what was approved, what was changed and what was actually spent, all at once. What you want to avoid is the new position overwriting the old one, because then the very figure you need to account for afterwards disappears.
Being able to click through from top to bottom: from a total in the annual accounts down to the underlying postings, and from a posting to the document and approval behind it. That takes a few properties. Postings can be corrected but not overwritten, so the original entry stays on record. Every approval records who, when and under which mandate, in a log that even an administrator cannot rewrite. Commitment, invoice, performance statement and payment are linked to one another. And the auditor can draw a sample and export it themselves.
Often yes, and for some organisations that is the wiser route. Mature financial packages exist for the public sector, with the prescribed structure of programmes and task areas built in, and with suppliers who update their product when reporting rules change. Custom becomes interesting at the layer around it: an environment where budget holders see their own position and record commitments, your own allocation or granting model, or integrations with line-of-business applications where the figures originate. The middle route is common: an off-the-shelf package as the general ledger, custom software at the front.
The source code and documentation belong to the client and sit in a repository to which you have direct access. Handover includes a description of the architecture, the data models, the integrations and the deployment, so another party can take over without first having to reverse-engineer anything. We work with mainstream technology, because that determines how many parties can take on the maintenance. For financial administration, this also includes a description of the coding structure and of the calculation rules behind depreciation, recharges and cost coverage.
Related services
Custom procurement software
The commitment arises at the award, so within the procurement process. For request, award, contract and performance confirmation in one chain: custom procurement software.
Custom audit software
If your question is mainly about the audit work itself, with the work programme, findings and follow-up across years, then custom audit software is the broader subject.
Custom grant management software
If you award funds yourself, then the decision, conditions, advance payments and final settlement belong together: custom grant management software. For reconciling bank transactions and subledgers, financial reconciliation software is the place to start.
A closer look at your budgeting and accountability process
Tell us how your budget is currently put together, at what point a commitment becomes visible in your administration, and what your accountant could not trace for themselves last year. Those three answers usually show whether a package, custom development or a combination fits best, and where the first gains lie.