Back-office software is bought on a demo and lived with for a decade. These are the questions that tend to separate the systems that hold up from the ones that are a database with forms on top.
**Is it double entry, or is it a billing screen?** Ask to see the chart of accounts, journals, voucher types and a period close. A system that records invoices and payments but cannot produce a trial balance is an invoicing tool; it will need a real ledger behind it, and you will be reconciling the two forever.
**What happens at the boundaries?** The interesting failures are between departments. When a goods receipt is posted, does the asset get created, does depreciation start, and does the journal appear — automatically? When a pay run is approved, does it reach the payroll accounts without a journal typed by hand? Bring your own scenario to the demo and follow it across modules.
**Where does approval live?** Look for an approval matrix by spend category and threshold, an inbox for approvers, and a transition that is refused when the approval is missing — enforced by the system, not by convention. Then ask what the audit trail records, and look at it.
**Can the people doing the work serve themselves?** Employee self-service for payslips, leave and personal details, and a vendor portal for pre-qualification and contracts, remove a surprising share of the administrative load — and they are the first things to be quietly missing.
**How do you get a number out?** Pre-built statutory reports, plus a builder for the ones nobody anticipated, plus scheduling so the recurring ones arrive on their own. If every non-standard question is a support ticket, budget for that.
**What does multi-entity actually mean here?** If you run more than one company, site or campus, consolidation has to handle intercompany elimination and currency translation, and scope every screen and report by entity. "Multi-entity" that means "you can type the entity name in a field" is not multi-entity.