The functional map of a finance system.

The general ledger and everything anchored to it: chart of accounts, journals, payables, receivables, and the period close. This is the module every other one posts into, and the one a finance team lives in daily.

Reporting and analytics over everything the system holds: statutory statements, ad hoc queries, dashboards, and the export route into whatever warehouse the business already runs. The question is rarely whether reports exist, but whether finance can change one without a consultant.

Requisitions, purchase orders, and the approvals between them, through to matching a supplier invoice against what was ordered and received. Where spend control is either enforced or quietly bypassed.

Tracking what stock exists, where it sits, and what it is worth. The valuation method it supports is usually what decides whether a distributor or manufacturer can use the system at all.

Projects as a costing object: budgets, time and expense booked against them, work in progress, and the billing rules that turn effort into revenue. For a services business this is effectively a second ledger, and it has to reconcile with the first.

Working out what will be needed and getting it there: demand forecasts, replenishment planning across sites, supplier schedules, and the freight and duty that arrive with the goods. Distinct from procurement, which executes the buying this module decides on.

Employee records, time and absence, and the pay run itself. The line to watch is where the vendor's own payroll stops and a local partner takes over, because that boundary tends to fall exactly at the countries you operate in.

Accounts, contacts, opportunities and quotes, held close enough to the ledger that a won deal becomes a sales order without rekeying. Most finance buyers already own a CRM, so what matters is whether this one replaces it or has to live beside it.

Bills of material, routings, work orders, and the planning run that decides what to make and when. Systems differ most in how they cost a job and how much shop-floor reality (scrap, rework, substitutions) they can absorb without invalidating the plan.

Running the building: bin-level locations, directed putaway and picking, scanning, and the wave and packing logic that decides what a picker does next. Distinct from inventory management, which knows what you own; this knows where it is and who last touched it.

The fixed asset register and its depreciation runs (capitalisation, useful life, disposals, revaluation) and in some systems the maintenance of physical plant as well. Worth establishing which of those two a vendor means, because both are sold under this name.

Inspection plans, holds, non-conformance and corrective action, plus the certificates and traceability records a regulated customer or auditor will ask for. In food, pharma and aerospace this is not an optional module; it is what makes the system auditable.

The storefront, or more often the connectors to one, and the plumbing that keeps orders, stock levels, pricing and returns in step between the shop and the ledger. Whether the vendor sells its own store or integrates yours changes the shape of the whole project.

The assistive layer vendors bolt onto the transactional core: invoice capture and coding, anomaly flags on journals, cash forecasts, natural-language querying of reports. The gap between what gets demoed and what is generally available is wider here than in any other module.

Work orders, scheduling and dispatch for technicians who go to the customer, plus the parts they consume and the contract or warranty that decides who pays. It only earns its keep when van stock and technician time both land in the ledger without a re-key.

The country-specific layer: local chart of accounts, statutory report formats, tax rules, e-invoicing clearance, and the languages the interface and printed documents run in. This is where an otherwise capable system quietly turns out to be unusable in a given market.