Financial accounting

The financial accounting capability is one of the two most heavily deployed parts of d1kit. It has been configured for regulators, religious institutions with hundreds of remitting units, hospitals, agricultural businesses and cooperative societies - the same core, configured differently.

Chart of accounts and the ledger

A configurable chart of accounts underpins everything, with account groups and hierarchies you define rather than inherit. Postings are double-entry: every transaction balances, and every balance is traceable back to the entries that produced it.

Accounts can be scoped by business unit, branch or department, so a group with many operating units gets both consolidated and per-unit views without maintaining separate books.

Budgeting and commitment control

Budgets are set per account, per period and per unit, and actuals are tracked against them continuously. Spending can be checked against available budget at the point of request rather than discovered at month end, which is what turns a budget from a report into a control.

Budget reconciliation - comparing planned, committed and actual positions across periods - is a capability the platform was originally built around, and remains one of its strongest.

Procurement and expenditure

The procurement cycle is supported end to end: requisition, approval routing, purchase order, goods or service receipt, invoice matching and payment. Each step carries its own approval rules and its own audit trail.

Because procurement shares the workflow engine with everything else, an organisation’s real approval hierarchy - including delegation, thresholds and multi-stage sign-off - is configured rather than coded.

Remittances and contributions

For organisations that collect from many units - dioceses and parishes, cooperative societies, member associations - the platform handles remittance definitions, expected contribution schedules, receipting and arrears tracking, with each remitting unit able to see its own position.

This is the capability behind deployments spanning several hundred remitting units.

Receivables, payables and reconciliation

Customer and supplier accounts, ageing analysis, credit control, and bank reconciliation against imported statements. Reconciliation is a first-class function rather than a spreadsheet exercise performed outside the system.

Payments and disbursement

Electronic payment and disbursement is supported, including bulk disbursement to large beneficiary registers. Deployments have used this to disburse grant funding electronically at national scale.

Payment provider integration is a configuration matter, so a deployment uses whichever provider its banking arrangements require.

Reporting

Standard financial statements - trial balance, income statement, balance sheet, cash flow - plus management reporting: budget performance, spend by unit or category, ageing, remittance compliance.

Reports can be scheduled, exported and, where another system needs them, exposed over the REST or GraphQL interfaces rather than emailed as attachments.

Controls and audit

Every financial record carries who created it, who last changed it and when. Approvals are recorded against the person who granted them. Records are retired rather than destroyed, so a historical position can always be reconstructed.

Segregation of duties is enforced through role and privilege configuration: the person who raises a requisition, the person who approves it and the person who releases payment can be required to be three different people.

Configuration, not customisation

The point worth emphasising for an evaluation: the differences between a diocesan finance deployment, a regulator’s fee-processing system and a hospital’s revenue cycle are largely configuration - chart of accounts, approval rules, document types, reporting lines - not new code. That is where the reduction in delivery time comes from.

Where genuinely bespoke behaviour is required, it is added as a module by a partner firm with codebase access.