At its centre is a general ledger core: a chart of accounts, double-entry journal entries with balanced debit and credit lines, fiscal years and periods with controlled open and close, a trial balance, and standard financial reports. Around that core the module runs the full breadth of corporate accounting. It maintains subledgers for receivables and payables, a fixed asset register with depreciation, inventory valuation, intercompany transactions and consolidation, recurring journals, accrual and prepaid schedules, cost allocations and withholding tax.

Beyond bookkeeping it carries the operational layers that most finance functions run day to day. Collections drives the recovery of overdue receivables through collector worklists, strategies, promise-to-pay tracking, dispute cases, risk scoring and escalation. Treasury executes payments over SEPA, ACH and wire, generates bank-format payment files, imports and reconciles bank statements, and forecasts liquidity. Payment terms, dunning and multi-GAAP reporting round out a module built to be the single place where the organisation keeps its books and controls its money.

Underneath the module is a conventional but strictly enforced ledger structure. A legal entity keeps its own set of books, in its own base currency, across defined fiscal years and periods that open and close under control. The chart of accounts classifies every balance, and the single unit of record is the journal entry: a header with two or more lines whose debits and credits must net to zero before it can post. Everything the module reports, from a trial balance to a statutory filing, is derived from those postings rather than stored alongside them, so the numbers can never disagree with the ledger that produced them.

The subledgers extend that core without breaking it. Customers and suppliers carry the financial master data, while sales invoices, receipts, vendor invoices and payments record what is owed and paid, each posting through to the general ledger rather than living in a silo. Connected registers hold fixed assets and their depreciation, inventory and its movements, bank accounts and their statements, and the tax codes that drive VAT and withholding. The operational layers sit on top of these: collections keeps its worklists, promises to pay and dispute cases, and treasury keeps its payment runs, cash positions and liquidity forecasts. One rule runs through all of it. Every monetary value is stored as a fixed-precision decimal rather than a floating-point number, which is what lets each subledger reconcile to the general ledger to the cent.

The order-to-cash path runs from a posted sales invoice through cash application, where incoming receipts are matched to open items, on to aging and customer statements. Where invoices fall overdue, the AR subledger hands open items, balances and aging to Collections, which prioritises them into collector worklists by risk, exposure and age, drives calls, letters and automated correspondence, records promises to pay, and manages disputes to resolution. When a dispute ends in a credit memo or write-off, the financial posting returns to AR, keeping accounting and operations cleanly divided but continuously in step.

The procure-to-pay path mirrors it. Vendor invoices are entered and matched two-way or three-way against purchase orders and receipts, then a payment proposal selects what must be paid by due date, discount and payment block. The proposal flows into Treasury, which runs the payment batch, generates the bank file, obtains approval, and executes over SEPA, ACH or wire. Imported bank statements are then reconciled, clearing the paid vendor items back in the AP subledger. Period-end brings its own workflows: recurring journals, accrual and allocation runs, depreciation, FX revaluation, dunning runs and, finally, period and year-end close.

The module is built to satisfy accountants, not just to record numbers. It runs parallel ledgers per entity per GAAP with a mapping engine that reclassifies, revalues or eliminates between standards, so a single set of events can be reported under IFRS and a local standard at once. Revenue recognition follows the five-step model of IFRS 15 and ASC 606; leasing computes the present-value liability and right-of-use asset under IFRS 16 and ASC 842; financial instruments carry IFRS 9 classification and hedge designation. Tax depth includes VAT and sales tax codes, a Dutch-style VAT return, withholding tax with thresholds, deferred tax from carrying-amount versus tax-base differences, and XBRL filing against ESEF, Companies House and SEC taxonomies.

Control is treated as a first-class concern. Treasury enforces segregation of duties: payment execution is deliberately separated from AP invoice entry, payment runs require dual or treasury approval, and positive pay guards cheque fraud in US environments. Bank reconciliation applies configurable matching rules with amount tolerances and reference patterns, flagging exceptions rather than forcing matches. SOX-ready internal controls, segregation rules with severity levels, an on-demand duty-conflict check and a transaction-level audit trail underpin the whole module, and fine-grained permissions gate each feature so that, for example, a user may hold receivables access without collections rights.

Accounting & Control is the financial hub of the suite, and much of what it posts originates elsewhere. Purchase orders raised in the Procurement module are the reference for two-way and three-way matching of vendor invoices; sales activity feeds the receivables it invoices and collects; and stock events reconcile against its inventory valuation. The Connector Management module handles inbound bank feeds and file parsing, delivering statements the module reconciles and receiving the payment files it generates for transmission over EBICS, SWIFT and host-to-host channels.

Identity and access come from System Administration, whose roles carry the coarse Accounting subject and the fine-grained subjects for chart of accounts, receivables, collections, payables, treasury and the rest. Because the ledger is the point where every operational module's activity becomes money, it is positioned above system internals in the suite and serves as the reconciliation point for the organisation: whatever happens in procurement, sales or operations, the balanced entry lands here, under one chart of accounts, in one auditable trail.

Nashua 360 treats AI Workers as first-class users of the module, subject to the same fine-grained permissions and audit trail as any person. They query module data conversationally, so a controller can ask for the receivables aging by risk tier, the current cash position across bank accounts, or the drivers behind a moved DSO, and receive an answer drawn from live ledger and subledger data rather than a static report. They also execute actions within their granted rights: drafting a payment proposal from AP due dates, preparing a recurring or accrual journal, or assembling a collector worklist for review.

Their sharpest value is in exception and anomaly work. An AI Worker watches for unreconciled statement lines, broken promises to pay, duplicate vendor invoices, segregation-of-duties conflicts and payments that deviate from a vendor's pattern, raising them before they become losses. They extract structured data from incoming documents, turning a vendor invoice or bank advice into matched, coded lines. And they participate directly in workflows as approval or review nodes: an AI Worker can screen a payment run for fraud indicators, verify a three-way match, or check a proposed action against segregation rules and block it, holding the item for a human where policy demands. In every case the ledger remains the authority, the decimal arithmetic stays exact, and the AI Worker's actions are logged like any other.