Quick answer: Finance ERP total cost of ownership should include software subscriptions, implementation, data migration, integrations, environments, storage, support, internal staffing, renewal changes and eventual exit costs. Compare vendors over the same period and business scope. Keep public prices separate from written quotes, and test how user growth and ongoing maintenance change the total.
A useful cost model answers two questions: What will this system require from the business, and when will those costs arise? For CFOs, controllers and implementation leads, the goal is not simply to find the lowest subscription price. It is to compare complete, deliverable solutions without hiding work in another department’s budget.
1. Set the scope before comparing prices
Choose a common evaluation period—such as three or five years—and give every bidder the same assumptions:
- Legal entities, countries, currencies and required finance modules.
- Users by task, access level and planned rollout date.
- Source systems and historical data to migrate.
- Interfaces, reports, approval workflows and customizations.
- Production, testing, training and development requirements.
- Support coverage and internal responsibilities.
Separate implementation costs, recurring operating costs and transition or exit costs. A practical model is:
Multiyear TCO = implementation and transition costs + recurring costs across the evaluation period + modeled exit costs.
Keep expected benefits outside this calculation. Evaluate savings and business improvements separately, with their own evidence and assumptions.
Also maintain two views:
- Cash budget: payments to vendors, contractors and additional employees.
- Economic cost: cash costs plus the value of existing employees’ allocated time.
Do not count the same employee hours both as internal effort and as backfill expense without explaining the distinction. Track costs when incurred and payments when due; an annual prepayment can affect cash flow differently from its monthly price presentation.
2. Build licensing from tasks, not job titles
Create a licensing matrix containing each user group’s tasks, required access, application, license type, quantity and start date. Microsoft’s licensing guidance distinguishes full-access and limited-access licenses, and its security-role guidance connects permissions with license requirements. A title such as “manager” is therefore not enough to determine the right license. (microsoft.com)
Ask bidders to confirm:
- Which license supports each required task?
- Are there minimum purchase quantities?
- Are additional applications, reporting tools or extensions separately licensed?
- How are temporary users and indirect access handled?
- When can quantities increase or decrease?
For Dynamics 365 specifically, Microsoft states that pooling connections through another application does not reduce licensing requirements. Do not assume an integration makes underlying access free. (microsoft.com)
Use public pricing as a dated reference, not a negotiated quote. On October 26, 2026, Microsoft’s US Finance pricing page displayed $210 per user per month for Finance and $300 for Finance Premium, paid yearly. Microsoft explicitly labels displayed prices informational and subject to currency, country and regional factors. (microsoft.com)
Its UK Finance page displayed £161.50 and £230.70 respectively, per user per month, paid yearly, excluding VAT. These are regional published prices—not a currency-conversion comparison or a promise of your contract price. (microsoft.com)
Record the source date, currency, edition, billing commitment, tax treatment and quote expiry beside every rate.
3. Price implementation and migration as defined deliverables
Request an implementation breakdown rather than one unexplained professional-services total. Use separate lines for:
| Workstream | What to specify |
|---|---|
| Process design | Workshops, decisions, process documentation and ownership |
| Configuration | Entities, accounts, dimensions, posting rules and approvals |
| Reporting | Named reports, layouts, data sources and acceptance criteria |
| Security | Roles, access testing and control reviews |
| Testing | Integration tests, user acceptance tests and defect resolution |
| Training and cutover | Training materials, rehearsals, deployment and initial support |
For each line, request deliverables, exclusions, assumptions, customer effort and change-control rules. Where work is time-and-materials, include estimated hours, rates and approval thresholds.
Treat migration as a separate workstream. Define whether the scope covers opening balances, open invoices, fixed assets, master records, transaction history and attachments. Specify extraction, cleansing, mapping, trial loads, correction cycles and final loading.
Make reconciliation part of the acceptance criteria. For example, require finance sign-off on the migrated trial balance and relevant AP, AR and fixed-asset totals against approved source records.
Budget for business participation: account mapping, data correction, test execution and approval do not become costless because employees already receive salaries. Include cutover rehearsals and a fallback plan, not just the final migration weekend.
4. Give every integration a build cost and a running cost
Use an integration register with one row per interface. Name its business owner, technical owner, source, destination, data objects, frequency and acceptance criteria.
For each interface, request separate estimates for:
- Initial configuration or development.
- Middleware, connector and related subscriptions.
- Mapping and transformation.
- Error handling, monitoring and reconciliation.
- Testing after changes to either connected system.
- Ongoing support and maintenance.
A proposal that says “payroll integration included” needs clarification. Does it cover journals only, employee records, correction handling, or all of these? Who investigates a rejected transaction?
Test the proposed interface in a sandbox with representative data. Include missing dimensions, duplicate submissions and failed transfers—not only a successful transaction.
If AI agents are in scope, add a separate consumption assumption. Microsoft’s Finance pricing page says running prebuilt and custom agents requires Copilot Credits, with credits included in Finance Premium and additional purchasing options available. Do not equate access to an agent with unlimited usage. (microsoft.com)
Keep integration maintenance visible even when the initial build is bundled into implementation.
5. Include environments, storage, support and internal administration
Ask for a written entitlement schedule showing what is included and what triggers additional charges.
For example, Microsoft’s licensing guidance lists one production environment and one nonproduction Tier 2 sandbox for Finance, with additional capacity and environments available for purchase. That does not establish what every ERP vendor—or every deployment—includes. (microsoft.com)
Check requirements for concurrent testing, training, development and performance testing. For storage, request the applicable database, file and log allowances, charging units and treatment of nonproduction copies. Model retention and attachment growth using your own data inventory rather than an unsupported industry average.
Deployment changes the responsibility boundary. Microsoft’s on-premises deployment documentation assigns infrastructure, high availability, disaster recovery, sandbox provisioning and infrastructure maintenance to the customer. A cloud subscription and an on-premises software quote therefore need different supporting cost lines. (learn.microsoft.com)
For support, distinguish product incidents from application administration and enhancement work. Ask who handles failed jobs, user access, reporting changes and post-update testing. Confirm coverage hours, escalation routes and contractual response commitments.
Assign internal hours for a finance system owner, administrator, integration owner and finance process specialists. Obtain estimates from the people expected to perform the work.
6. Use a transparent multiyear worksheet
The following is a wholly hypothetical, product-neutral example, not a vendor estimate, market benchmark or implementation recommendation. Every amount is invented solely to demonstrate the calculation.
Assumptions:
- USD, undiscounted, three operating years.
- Year 0 contains implementation; subscriptions and operating costs begin in Year 1.
- Forty users at an assumed $100 per user per month.
- No user growth or price increases in the base case.
- Taxes, foreign-exchange changes, financing, contingency and benefits are excluded.
- Legacy overlap, retirement and an exit allowance are grouped in Year 0 for simplicity; an actual model should place them in their expected periods.
| Cost item | Year 0 | Year 1 | Year 2 | Year 3 |
|---|---|---|---|---|
| External implementation | $120,000 | — | — | — |
| Data migration | $30,000 | — | — | — |
| Integration build | $36,000 | — | — | — |
| External training and change support | $12,000 | — | — | — |
| Internal project time: 600 hours × $60 | $36,000 | — | — | — |
| Legacy overlap, retirement and exit allowance | $9,000 | — | — | — |
| User subscriptions: 40 × $100 × 12 | — | $48,000 | $48,000 | $48,000 |
| Integration maintenance | — | $9,000 | $9,000 | $9,000 |
| Additional environments and storage | — | $6,000 | $6,000 | $6,000 |
| External support | — | $12,000 | $12,000 | $12,000 |
| Internal administration: 400 hours × $60 | — | $24,000 | $24,000 | $24,000 |
| Total | $243,000 | $99,000 | $99,000 | $99,000 |
Three-year economic TCO: $243,000 + (3 × $99,000) = $540,000.
The subscription-only total is $144,000. The difference demonstrates this worksheet’s scope—not a typical ERP cost ratio.
Now change the assumptions:
| Scenario | Change from base | Revised TCO |
|---|---|---|
| Base | Forty users; maintenance stays flat | $540,000 |
| User growth | Forty, 48 and 58 users in Years 1–3, each billed for the full year | $571,200 |
| Higher integration maintenance | $9,000, $13,500 and $18,000 in Years 1–3 | $553,500 |
| Combined | Both changes above | $584,700 |
For user growth, the additional subscription cost is:
[(48 − 40) + (58 − 40)] × $100 × 12 = $31,200.
These scenarios hold all other costs constant to isolate the effects. In a real assessment, revisit administration, storage and training when users or transaction volumes grow. Replace the example’s billing start with the actual contractual start date.
7. Check renewals, omissions and double counting before approval
Add a renewal schedule showing contract end dates, notice deadlines, discount expiry, quantity-change rights and any documented price protections. If a future rate is unknown, label it an assumption—not “fixed.”
For sensitivity testing, an assumed 5% annual subscription increase from Year 2 would raise the example’s flat-user subscription costs to $50,400 and $52,920 in Years 2 and 3. That adds $7,320 to base TCO. It is a planning scenario, not a forecast.
Before signing off, check that:
- Scope matches: every proposal covers the same entities, workflows, interfaces and reports.
- Included means priced: bundled items are identified, with no duplicate charge elsewhere.
- Customer work has an owner: internal hours are agreed, not silently assumed.
- Billing follows the contract: paid-yearly prices are not treated as cancellable monthly commitments.
- Exit is addressed: obtain terms for data export, attachment retrieval, transition assistance and legacy access.
- Uncertainty remains visible: distinguish quoted, estimated, optional, excluded and unresolved costs.
Keep any contingency reserve separate from expected TCO and explain what risks it covers. The final approval should show the base estimate, sensitivity cases, cash requirements and unresolved commercial questions—not just one reassuring total.