At its foundation is a general ledger with a configurable chart of accounts, journal entry posting, fiscal period and year management, multi-currency valuation with foreign exchange revaluation, and the full set of standard statements: trial balance, profit and loss, balance sheet and cash flow. Around this core sit the operational subledgers, each held deliberately apart from its workflow counterpart. Accounts Receivable owns invoicing, cash application, aging and reconciliation to the ledger, while Collections runs the credit-to-cash operation beside it. Accounts Payable owns vendor invoices, purchase-order matching and the vendor subledger, while Treasury executes payment and bank integration.

Fixed assets carry full registers with depreciation across multiple books, inventory is valued on weighted-average costing with movement-level journals, and intercompany transactions feed consolidation groups with currency translation and elimination entries. On top of this the module ships the operational machinery a controller relies on daily: payment terms, recurring journals, automated accruals and prepayments, cost allocation, withholding tax, dunning, budget revisions and variance analysis, and a document store that attaches source evidence to any record.

The model begins with the legal entity, the company that keeps its own books, reports in a functional currency and closes on its own fiscal calendar. Several entities coexist and roll up into groups for consolidation, with the relationships between them tracked so that balances owed one another can be eliminated on the way to a group view.

Every entity keeps a chart of accounts, the structured list of ledger accounts classified as assets, liabilities, equity, income or expense. Value moves through the books only as a journal entry: a balanced posting whose debits equal its credits, carrying date, currency, description and a link to the fiscal period it lands in. This discipline is absolute, and it is what lets the books always reconcile.

Between the raw ledger and the outside world sit the subledgers, the detailed records of who owes what and to whom. Customers and their invoices, receipts and disputes live on one side; suppliers, their invoices, matched purchase orders and payments on the other. Each subledger summarises into control accounts in the general ledger, so an aging report and the balance sheet always tell the same story. Fiscal periods gate all of this, opening to accept postings and closing to freeze them, giving the close its structure and the audit trail its integrity.

The transaction-to-close cycle is the spine. Entries originate directly or flow in from operational modules, post to the ledger and their subledgers, accrue and allocate on schedule, revalue for foreign exchange at period end, and reconcile before the period is closed and the next opened. Year-end close aggregates profit and loss balances, posts the closing entry to retained earnings and locks the year.

Credit-to-cash runs from invoice issuance through cash application, matching receipts and remittances to open items, into Collections where prioritised worklists, strategies, promise-to-pay tracking and dispute cases drive recovery, with write-offs and credit memos posting back to the ledger. Procure-to-pay moves the other way: vendor invoices are captured, matched two-way or three-way against purchase orders and receipts, approved, and assembled into payment proposals by due date and discount.

Treasury then executes. Approved proposals become payment runs over SEPA, ACH, wire and cheque, generating ISO 20022 payment files, passing dual approval, and clearing subledger items once the bank confirms. Imported statements reconcile automatically against open entries using configurable matching rules with tolerances, and cash positioning and liquidity forecasting project the balance forward. Consolidation runs aggregate entity trial balances, translate currency and eliminate intercompany positions to produce the group result.

The module maintains parallel ledgers, one per accounting framework, so a single entity reports under local GAAP, IFRS and US GAAP simultaneously. A mapping engine translates postings between frameworks with reclassification, revaluation and elimination adjustments, and a policy engine records the recognition, measurement and disclosure rules that govern each standard. Revenue recognition implements the five-step model of IFRS 15 and ASC 606, identifying performance obligations, allocating transaction price against standalone selling prices and recognising over time or at a point in time. Leasing follows IFRS 16 and ASC 842, computing the present value of the lease liability, the right-of-use asset and a full period amortisation schedule. Financial instruments are classified, measured and impaired under IFRS 9.

Tax is treated with equal rigour: VAT and sales tax computation, jurisdiction-aware returns, deferred tax from carrying-versus-tax-base differences, withholding tax at payment, and XBRL filing against ESEF, Companies House and SEC taxonomies with balance-sheet cross-checks. Controls are SOX-ready, with defined internal controls, segregation-of-duties rules that block conflicting actions in real time, dual payment approval, positive pay and a complete audit trail. Every monetary value is held as a fixed-precision decimal, so rounding never erodes the books.

Accounting & Control is the financial backbone the rest of the suite posts into. Procurement raises the purchase orders that Accounts Payable matches invoices against, and receipt confirmations complete the three-way match. Sales and CRM originates the orders and customer relationships that become receivable invoices, and shares credit limits and risk flags with Collections. Inventory and Supply Chain drives stock movements that value into the ledger and reconcile to inventory control accounts, while Projects contributes cost allocation bases and revenue contracts for recognition.

Treasury reaches the banks through Connector Management, which carries EBICS, SWIFT and host-to-host channels and delivers statement files for reconciliation. Human Resources and Payroll posts its payroll runs and accruals directly into the general ledger. Access across all of this is governed centrally: the Identity and Access layer resolves the fine-grained permissions that decide who may post a journal, approve a payment or view a subledger, and the segregation rules that keep those duties apart. The result is a suite where operational events and their accounting are one continuous record rather than a nightly reconciliation between disconnected systems.

Nashua 360 treats AI Workers as first-class users of the module, holding the same permissions and passing through the same controls as any person. They answer questions conversationally against live ledger and subledger data, so a controller can ask why an account moved, which invoices drive an aging bucket, or how a balance reconciles, and receive an answer grounded in the actual postings. They execute work directly: drafting journal entries, assembling payment proposals from due invoices, running depreciation or an accrual schedule, and preparing a VAT return for review.

Continuously, they watch for anomalies and exceptions: unbalanced or unusual entries, duplicate vendor invoices, broken promises to pay, reconciliation breaks, segregation-of-duties conflicts and approaching filing deadlines, raising each to the right owner. They extract structured data from source documents, reading vendor invoices, remittances and bank statements into posted transactions with the evidence attached. And they act as decision support and as formal nodes in the approval and review workflows, standing in an approval chain for a payment run or a period close, applying policy consistently, recording their reasoning, and escalating anything that falls outside tolerance to a human authority.