Quick answer: Build your finance ERP request for proposal around business scenarios, not feature checklists. Give each requirement an owner, priority, pass condition and evidence request. Then make shortlisted vendors demonstrate the same purchasing-to-payment workflow—including an invoice exception—in the edition and configuration they propose. Evaluate mandatory requirements before comparing weighted scores.
For CFOs, controllers and implementation leads, the deliverables should be practical: a requirements matrix, a common vendor response template, a scoring model and a demonstration script. Keep the same requirement IDs throughout selection and implementation so a successful demonstration can become a starting point for acceptance testing.
1. Interview the people who perform and control the work
Start with business processes before asking vendors to suggest solutions. Interview accounts payable, purchasing, receiving, treasury, general ledger, reporting, IT and the people who approve transactions. Include the executive sponsor to resolve competing priorities.
Ask each stakeholder:
- What starts the process, and what confirms completion?
- Which information is entered twice or corrected manually?
- What exceptions require investigation?
- Who can approve, change, post or release the transaction?
- Which documents and reports prove that the result is correct?
- What happens when an approver is absent or an integration fails?
Request anonymized examples of an ordinary transaction and a difficult one. Do not send vendors production credentials, bank details or identifiable supplier records.
Record actual operating needs: legal entities, currencies, purchasing arrangements, reporting dimensions, connected systems and transaction volumes. Where information is unavailable, mark it to be confirmed and assign an owner.
Separate the business outcome from the preferred implementation. “Route an invoice variance to the responsible buyer” leaves room for different designs. “Reproduce our current spreadsheet approval process” may preserve a workaround without explaining why it exists.
End each interview with a named requirement owner and a proposed acceptance check.
2. Turn requirements into observable pass conditions
A useful requirement describes an actor, an action, a condition and an expected result.
Instead of “supports invoice matching,” write:
When an AP clerk enters an invoice whose quantity exceeds the recorded receipt, the system must identify the discrepancy and prevent unauthorized progression under our agreed exception policy.
Define the matching method precisely. Microsoft’s Dynamics 365 Finance documentation distinguishes two-way price matching from three-way matching, which also compares invoice quantities with selected product receipts. A generic “matching supported” response does not establish which checks are performed. (learn.microsoft.com)
Use three priorities:
- Must-have: Required for the agreed go-live scope; failure needs an explicit exclusion decision or approved remedy.
- Should-have: Valuable, but an acceptable alternative may exist.
- Optional: Useful only after critical requirements are satisfied.
The following is a sample matrix, not a claim about any product’s capabilities.
| ID | Testable requirement | Priority | Owner | Pass condition and evidence |
|---|---|---|---|---|
| P2P-01 | Route a purchase request to the appropriate approver | Must | Purchasing | Demonstrate routing using the supplied department and approval rules |
| AP-01 | Identify price and receipt-quantity discrepancies | Must | AP manager | Show both exceptions in the supplied test invoice |
| CTRL-01 | Restrict exception approval to an authorized role | Must | Controller | Demonstrate a denied attempt and an authorized resolution |
| PAY-01 | Exclude an unresolved invoice from payment | Must | Treasury | Show payment selection before and after resolution |
| GL-01 | Trace a posted invoice to its ledger entries | Must | Controller | Display the voucher, accounts, dimensions and source document |
| INT-01 | Recover a failed invoice import without duplicate posting | Must | IT lead | Demonstrate error handling, correction and resubmission |
| RPT-01 | Report the transaction by department | Should | Finance director | Reconcile report output to the posted transaction |
| UX-01 | Personalize an AP work queue | Optional | AP manager | Demonstrate with the intended user role |
Add columns for vendor response, proposed product, edition, configuration, dependency, implementation effort, recurring cost and evidence reference.
Require vendors to distinguish standard functionality, configuration, partner add-ons, custom development, unavailable capability and roadmap items. Do not treat planned functionality as available.
3. Require edition, licensing and dependency evidence
Every vendor answer should identify what the proposal actually includes:
- Product, edition and demonstrated release.
- Deployment model and applicable country or region.
- Required modules, partner applications and external services.
- User roles and license types.
- Capacity allowances and additional consumption charges.
- Sandbox, integration, reporting and support dependencies.
Ask for official documentation and a written commercial explanation. A capability visible in a demonstration is not enough; require confirmation that the quoted configuration and licenses permit your intended use.
Microsoft’s current guidance illustrates the importance of edition-specific checks. Dynamics 365 Finance includes 100 invoice-capture transactions per tenant per month, while Finance Premium includes 200. The guidance also states that included capacity does not roll over and is capped at tenant level rather than multiplied by the number of licensed applications. Confirm the applicable terms when obtaining a quote. (microsoft.com)
For reporting, Microsoft distinguishes financial report designers, who need a Finance user license, from viewers, who need a Team Members license. “Needs reporting access” is therefore too vague for a user-count worksheet. (microsoft.com)
Map people to tasks rather than job titles alone. Microsoft documents that assigned security roles determine licensing requirements in its finance and operations applications, and custom roles can require licenses for more than one application. (learn.microsoft.com)
These examples are checks to apply, not a recommendation to select Microsoft. Request equivalent evidence from every shortlisted vendor.
4. Agree on scoring before demonstrations begin
Use two separate decisions: mandatory qualification and comparative scoring.
First, assess must-haves. Mark each pass, fail or unverified. An unverified requirement should not quietly become a pass because the vendor performed well elsewhere.
Then compare qualified proposals using agreed weights. An illustrative model is:
| Category | Weight |
|---|---|
| Financial workflow fit | 40% |
| Controls and traceability | 25% |
| Integration and administration | 15% |
| Reporting and usability | 10% |
| Commercial clarity and delivery scope | 10% |
For each scored criterion, use a common evidence scale:
- 0: Unavailable or not evidenced.
- 1: Described, but not demonstrated.
- 2: Partially demonstrated or dependent on unresolved work.
- 3: Demonstrated against the agreed pass condition.
- 4: Demonstrated, with configuration and operational evidence also verified.
Calculate each contribution as:
Category score ÷ 4 × category weight
For example, hypothetical category scores of 3, 4, 2, 3 and 4 produce:
30 + 25 + 7.5 + 7.5 + 10 = 80 out of 100
That score does not override a failed mandatory control.
Have evaluators score independently before discussing results. Record the evidence reference, unresolved assumptions and reasons for each score. Keep subscription and implementation costs visible separately rather than hiding them inside an overall rating.
5. Run one purchasing-to-payment script with a deliberate exception
Give every vendor the same synthetic dataset and expected outcomes. Allow preparation, but require live execution and ordinary business roles—not only administrator access.
Synthetic scenario: A company orders 50 non-stock maintenance supply packs at $40 each. Only 45 arrive. The supplier invoice bills 50 packs at $42 each. For this test, exclude tax, freight, discounts and foreign exchange. Set a 2% unit-price tolerance and require an exception for quantities exceeding receipts.
The test contains two discrepancies:
| Check | Calculation | Expected finding |
|---|---|---|
| Ordered value | 50 × $40 | $2,000 |
| Received quantity | 45 versus 50 invoiced | Five packs invoiced but not received |
| Unit-price variance | ($42 − $40) ÷ $40 | 5%, above the test’s 2% tolerance |
| Submitted invoice | 50 × $42 | $2,100 |
| Corrected invoice | 45 × $40 | $1,800 |
Ask the vendor to execute this sequence:
- Create and approve the purchase. Show the requester, department, approval route and resulting purchase order.
- Record the partial receipt. Receive 45 packs, leaving five outstanding.
- Enter the supplier invoice. Use the original test values without silently correcting them.
- Expose both discrepancies. Show the price comparison and receipt-quantity comparison, along with the applicable rules.
- Test the control. Attempt progression as the AP clerk. Demonstrate what is prevented, what is permitted and who receives the exception.
- Check payment eligibility. Show whether the unresolved invoice appears in payment selection and how the required restriction is enforced.
- Resolve the exception legitimately. Record a documented supplier correction to 45 packs at $40, preserving evidence of the submitted values.
- Post and trace. Display the posted invoice, voucher, accounts, department dimension and remaining purchase-order quantity.
- Demonstrate payment and settlement. Use a sandbox or simulated payment process; do not transmit a real bank instruction.
Do not assume that a warning automatically blocks posting or payment. Microsoft’s matching overview describes discrepancy indicators when tolerances are exceeded; the demonstration must establish the actual control behavior in the proposed configuration. (learn.microsoft.com)
For a simplified illustration, assume receipt creates no ledger entry and the corrected supplies are expensed when invoiced. The invoice would debit maintenance expense and credit AP by $1,800; payment would debit AP and credit bank by $1,800. This is a synthetic test assumption, not a posting prescription. Require the vendor to explain its actual receipt, accrual and payment-clearing entries.
6. Check the weak points a polished demo can hide
Use a short follow-up checklist rather than requesting another general presentation.
Check the role. Repeat critical actions with the proposed permissions. An administrator’s successful transaction does not establish that the intended user can perform it—or that an unauthorized user cannot.
Check the configuration. Ask where tolerances, routing and payment restrictions are maintained. Record who can change them and what evidence of changes is available.
Check recovery. Introduce a failed import or rejected transaction. Ask the vendor to correct and resubmit it, then prove that no duplicate invoice or ledger posting was created.
Check document continuity. Trace the purchase order, receipt, submitted invoice, correction, posted voucher and payment. Capture any steps that require external tools or manual reconciliation.
Check the quote. Match demonstrated add-ons, user roles and consumption services to commercial line items. Request an explanation for anything demonstrated but excluded.
Avoid scoring presentation quality as workflow fit. If the vendor substitutes slides, a recording or a different scenario, mark the requirement unverified and schedule a targeted follow-up.
7. Carry selection evidence into implementation acceptance
Before selecting a vendor, produce a decision pack containing:
- The completed requirements matrix and mandatory-requirement decisions.
- Demonstration evidence and unresolved gaps.
- Product, edition, role and licensing assumptions.
- Implementation responsibilities and integration boundaries.
- Cost inclusions, exclusions and usage assumptions.
- Agreed follow-up tests and business owners.
Convert successful demo scenarios into implementation acceptance scripts, but do not mistake the demo for completed acceptance testing. Add your migrated data, integrations, operating volumes and production-like permissions during implementation.
For each unresolved issue, record the remedy, owner, cost treatment, verification method and decision deadline. Ask what happens if the proposed remedy fails: reconfiguration, additional work, a controlled workaround or reconsideration of the selection.
The final selection question is not “Which system showed the most features?” It is: Which proposal demonstrated our essential workflows, disclosed its dependencies and gave us a testable path to acceptance?