Quick answer
To compare finance ERP systems, give shortlisted vendors the same business scenarios, sample data and acceptance criteria. Ask them to demonstrate complete workflows—including exceptions—using realistic user roles. Record what was demonstrated separately from documentation, sales statements and roadmap promises. Apply mandatory requirements before weighted scoring, then evaluate implementation assumptions and total cost separately.
A useful selection question is not simply, “Does the system support invoice approval?” It is: “Can our invoice preparer submit this invoice, route it under our approval policy, resolve a rejection and show the resulting accounting and approval history?”
The following approach is a proposed buyer-side evaluation method, not a product ranking. Adapt its scripts and weights to your organization.
1. Discover requirements with the people who perform the work
Start with a workshop involving accounts payable, receivables, treasury, the controller, reporting users, IT and the implementation lead. Include business approvers who will use the system occasionally.
Ask each participant to bring a sanitized example of a difficult transaction, reconciliation exception or report adjustment.
For each process, record:
- Trigger and inputs: What starts the work, and where does the data originate?
- Roles: Who prepares, approves, posts, reviews and administers it?
- Exceptions: What happens when data is missing, disputed or duplicated?
- Accounting outcome: Which balances, dimensions and periods should change?
- Evidence: What must a reviewer be able to inspect afterward?
- Operating needs: What transaction volumes, deadlines and peak periods must the solution accommodate?
Write requirements as observable outcomes.
Replace “flexible reporting” with:
“A finance analyst can produce a monthly income statement by department, compare actuals with budget and trace a selected expense balance to its supporting transactions.”
Assign an owner to every requirement. That person should approve the acceptance criteria and evaluate the demonstration.
2. Separate mandatory requirements from preferences
Use three priorities:
| Priority | Meaning | Selection treatment |
|---|---|---|
| Mandatory | Required for the agreed operating model or go-live scope | Must pass before final selection |
| Weighted | Important, but trade-offs are possible | Include in comparative scoring |
| Optional | Useful without being essential | Record without letting it dominate |
A mandatory requirement needs a specific test. “Strong controls” is too broad; “the invoice preparer cannot approve their own invoice under the proposed role design” is testable.
For each requirement, request written confirmation of:
- Product, edition and release demonstrated.
- Required modules, add-ons and third-party services.
- Configuration, extension or custom development needed.
- Relevant permissions and feature settings.
- Inclusion in the commercial proposal.
Do not accept a visible menu option as proof that a process will run. Microsoft’s vendor invoice documentation, for example, describes a batch-posting workflow task that is visible in the editor even when its feature parameter is disabled; the workflow will not process that task until the parameter is enabled. (learn.microsoft.com)
Mark an untested mandatory requirement unresolved, not passed. Require a follow-up demonstration or agreed proof of concept before committing.
3. Build a scorecard that keeps evidence separate from claims
Send vendors the scripts and scoring rules before the demonstrations. Use the same core scenarios and data for every candidate, while allowing a clearly separated session for additional capabilities.
Maintain an evidence register with these fields:
| Field | What to record |
|---|---|
| Requirement ID | Unique reference and business owner |
| Acceptance criterion | Observable result needed to pass |
| Evidence status | Demonstrated, documented only, claimed, roadmap or failed |
| Delivery method | Standard configuration, add-on, extension or manual workaround |
| Evidence reference | Demonstration timestamp, output or document reference |
| Follow-up | Open question, owner and due date |
Score observed performance separately from evidence status. A written assurance is useful, but it is not a completed demonstration.
A suggested demonstrated-fit scale is:
- 0: Failed or no acceptable solution shown.
- 1: Major gaps or substantial manual workaround.
- 2: Partially meets the criterion.
- 3: Meets the criterion.
- 4: Meets it and demonstrates an additional, relevant benefit.
Leave untested items not evaluated and report their weight separately.
Hypothetical worked example: Assume every category below has been demonstrated and the mandatory requirements have passed.
| Category | Weight | Score out of 4 | Weighted points |
|---|---|---|---|
| Invoice workflow | 25% | 3 | 18.75 |
| Bank reconciliation | 20% | 4 | 20.00 |
| Financial reporting | 20% | 2 | 10.00 |
| Integration operation | 15% | 3 | 11.25 |
| Access controls and audit evidence | 10% | 3 | 7.50 |
| Usability and administration | 10% | 2 | 5.00 |
| Total | 100% | 72.50/100 |
Calculate each contribution as weight × score ÷ 4. These are illustrative weights and scores, not vendor results.
Define category boundaries so that the same approval control is not rewarded twice. Preserve the category scores: a single total should not conceal a reporting weakness.
4. Script an invoice approval demonstration from entry to accounting
Prepare: A fictional supplier, an invoice, department coding and a written approval rule. For example, use a $6,000 invoice requiring two approvals under your hypothetical policy.
Ask the vendor to:
- Enter or import the invoice and show its attachment and coding.
- Submit it as an invoice preparer—not an administrator.
- Show the approval route and the rule that selected it.
- Attempt self-approval using the preparer’s role.
- Reject the invoice with a reason, correct it and resubmit.
- Complete approval and show the accounting and payment eligibility.
- Display the available history of changes and decisions.
Acceptance checks: The correct people receive the task; prohibited actions are blocked; rejection has a visible resolution path; and accounting occurs at the agreed stage.
Ask explicitly when the invoice affects the ledger. Oracle’s NetSuite documentation distinguishes pending, rejected and approved vendor bills: pending and rejected bills have no accounting impact in the status table, while approved bills do. It also distinguishes standard approval from custom SuiteFlow routing. Do not assume another ERP follows the same design. (docs.oracle.com)
Finally, ask what happens when an approver is absent or the invoice changes after approval. Record whether the answer was demonstrated or merely described.
5. Script bank reconciliation around ambiguous matches
A useful reconciliation test includes transactions that should not match automatically.
Prepare: A sanitized statement in a format your bank actually supplies, corresponding ledger transactions, a bank fee, an outstanding payment and two transactions with the same amount.
Ask the vendor to:
- Import the statement and show validation failures, if any.
- Display the matching rules and their execution order.
- Match a straightforward transaction.
- Process the ambiguous same-amount case.
- Resolve the bank fee through the proposed controlled process.
- Show outstanding items and the reconciliation output.
- Demonstrate how an incorrect match is corrected.
Acceptance checks: The outcome agrees with a manually prepared control schedule; ambiguous items follow your policy; and adjustments remain traceable.
This is a configuration question, not just a feature question. Microsoft documents that Dynamics 365 Finance matching rules default to the first bank transaction meeting the criteria. It provides a parameter requiring manual matching when multiple documents match on amount. (learn.microsoft.com)
Ask the vendor to show the actual settings. Record tolerances, date rules, transaction mappings and any enabled feature dependencies.
6. Script financial reporting back to the underlying transactions
Prepare: A small, balanced dataset with a known trial balance, department-coded expenses and a budget. Calculate the expected report totals independently.
Ask the vendor to:
- Produce the agreed income statement for a specified entity and period.
- Filter or split it by department.
- Add budget and variance columns.
- Trace a selected expense balance to supporting transactions.
- Identify an account or dimension combination omitted from the report.
- Make a permitted test adjustment and refresh the output.
- Repeat the exercise as a restricted reporting user.
Acceptance checks: Totals reconcile to the agreed ledger scope; signs and variance formulas are understandable; access follows the proposed design; and the refresh behavior is explained.
Ask whether the report uses live ledger data, a reporting store or an external analytics platform. Require the vendor to explain any refresh delay and demonstrate how the reporting user recognizes stale data.
Do not score an exported spreadsheet as equivalent to an ERP-maintained report unless that is an accepted part of your operating model. Record the manual steps and their owner.
7. Test integrations and make implementation assumptions explicit
Replace “API available” with a named interface requirement.
For each bank, payroll, billing, purchasing or other connected system, specify:
- Source, destination and business owner.
- Data objects, direction and required frequency.
- Expected volume and peak processing window.
- Authentication and proposed access.
- Duplicate prevention and retry behavior.
- Error alerts, correction process and support ownership.
- Reconciliation totals and evidence retained.
Ask the vendor to demonstrate one successful transfer and one failed transfer, then correct and replay the failure without duplicating the transaction.
Microsoft’s recurring integration documentation describes queue and processing-status monitoring, execution-error retrieval and batch-job troubleshooting. Those operational capabilities illustrate why evaluating an integration should go beyond proving that a file can be sent. (learn.microsoft.com)
For implementation, require written assumptions covering data cleansing, mapping, migration history, report rebuilding, role design, testing, training and customer staffing.
Ask: Who performs each task, what is excluded, and what evidence confirms completion?
Carry the scripts into user acceptance testing. Add cutover checks for opening balances, open invoices, bank items and reconciled control totals. Define go/no-go authority and fallback arrangements before production cutover.
8. Compare total cost and close the evidence gaps
Use a common evaluation horizon and shared assumptions for user counts, entities, volumes and rollout phases.
Request separate cost lines for:
| Cost category | Questions to resolve |
|---|---|
| Subscriptions | Which editions, user types, minimum commitments and renewal terms apply? |
| Add-ons and consumption | Which connectors, capture services, storage or usage allowances are included? |
| Implementation | What configuration, project management and localization work is covered? |
| Data and reporting | Who cleanses, migrates, reconciles and rebuilds reports? |
| Internal effort | What finance, IT, testing and training capacity must you supply? |
| Ongoing operation | Who supports integrations, changes and release testing? |
| Exit | What export, archive, access and transition arrangements apply? |
Edition labels matter. Microsoft’s licensing guidance distinguishes Finance and Finance Premium, while its pricing page warns that displayed prices are informational and can vary by country, currency and region. Treat a public price as a starting reference, not your complete commercial offer. (microsoft.com)
Before selection, check that:
- Mandatory requirements have passed.
- Important claims have demonstration evidence.
- Exceptions were tested, not skipped.
- The quotation includes the demonstrated components.
- Implementation responsibilities and exclusions are written down.
- Open issues have owners and resolution dates.
Do not change weights afterward to favor an impressive presentation. Select on the agreed evidence, delivery assumptions and commercial terms—not on the smoothest demonstration.