Quote-to-Cash on Dynamics 365 When the Process Lives in a Shared Spreadsheet

Why does a shared spreadsheet quote-to-cash process break down?

A workbook that started as one sales manager's price calculator becomes, over years, the price book, the discount policy, the approval record and the hand-off to finance at the same time. It works until enough people depend on it, and then the failure modes are always the same. None of them is fixed by a tidier workbook, because they come from the file being the system of record without any of the properties a system of record needs.

Compliance usually arrives with a short list of questions the spreadsheet cannot answer: who changed this price, who approved this discount, which version of the price list did this quote use, and can a seller approve their own exception. If the honest answer to each is "we would have to reconstruct it from emails", the process needs a platform, not a policy.

• Concurrency: co-authoring conflicts, locked files, copies saved locally and then re-merged by hand.
• Silent formula damage: an overwritten cell or a broken lookup range changes prices without anybody noticing.
• No enforced approval: the discount threshold is a note in a column header, not a control.
• No reliable history: version history shows that a file changed, not which price changed, why, and on whose authority.
• Re-keying into the ERP: every order is typed again by someone in finance, so the quote and the invoice can differ.

What does Dynamics 365 Sales give you out of the box for quote-to-cash?

More than most spreadsheet teams expect. The objects below are standard Dynamics 365 Sales on Dataverse and are configured, not built. What they do not do is just as important, and the volume discounts and complex pricing guide sets out exactly where the native pricing engine stops, so it is not repeated here.

What needs Power Platform on top of Dynamics 365 Sales?

Almost every spreadsheet replacement needs a layer on top of configuration, and it is better to scope it honestly at the start than to discover it in user acceptance testing. The pattern we use keeps anything that decides a number server side, so the rule holds for a form, an import and an integration alike, and uses Power Automate for the work that involves people or other systems.

• Discount approvals: a Power Automate approval triggered when a line or order discount crosses a threshold, routed by role or value into Teams or Outlook, with the outcome, approver and timestamp written back to the quote.
• A hard stop that cannot be bypassed: validation in a synchronous plugin so an unapproved quote cannot be activated, rather than a form script that an import ignores.
• Pricing rules the spreadsheet encoded in formulas: tiered or order level discounts, customer agreements and promotions, designed as described in the pricing guide.
• Fast line entry: where sellers are used to pasting dozens of lines into a grid, an editable grid or a custom PCF control keeps entry quick without leaving the governed record.
• Integration flows to finance or the ERP, covered below, including the acknowledgement and reconciliation that make them trustworthy.
• Scheduled checks: a nightly flow that reports quotes whose realised discount or approval state does not match policy.

How do the build-versus-buy options compare for replacing the spreadsheet?

There are four realistic options. The comparison is about fit, not about which product is better in general.

When is a custom application the right answer instead of Dynamics 365?

We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both. For quote-to-cash specifically, a custom CRM on React, Node.js, PostgreSQL or .NET is the better fit in a few recognisable situations, and none of them is "Dynamics 365 is a bad product".

Our custom CRM versus licensed CRM decision guide covers ownership, obligations and cost drivers in general; the quote-to-cash signals are below.

• The price is computed, not looked up: a rating or configuration engine with dimensions, formulas and dependencies where list price plus discount is the wrong shape, so the platform pricing engine would be switched off and rebuilt anyway.
• Many people need light access to quoting, or distributors and partners quote directly, and per-user licensing for all of them does not fit the budget.
• The quoting tool is the product: it must run inside your own portal or hosting, or under data residency rules a public cloud service cannot meet.
• Sellers do not need a CRM at all, only a governed quoting and order workflow feeding finance.

What controls will compliance ask for, and how are they met?

Auditors ask for evidence, not intent. On Dynamics 365 Sales each control below is met by platform features plus deliberate design; in a custom application the same controls have to be engineered explicitly, which is part of its cost.

How do you integrate a legacy ERP that has no proper API?

This is where spreadsheet replacements most often fail: the CRM goes live, the ERP cannot receive orders, and finance quietly starts a second spreadsheet to bridge the two. The fix is a deliberate integration contract, even when the ERP only understands a database table or a file. We build these with Power Automate cloud flows through the on-premises data gateway where the ERP side is on premises, or with a small integration service where volume or logic demands it.

• Staging tables: the CRM writes approved orders into a staging table the ERP team already knows how to import from, with a status column, never directly into ERP tables.
• File drop where there is no database access: a structured file per batch into an agreed folder, with a naming convention and a checksum or record count.
• Idempotent keys: every order carries the Dynamics 365 order number, so a re-sent batch cannot create a duplicate.
• Acknowledgement: the ERP import writes back an accepted or rejected status and the ERP order number, which the flow stamps onto the Dynamics 365 order.
• Reconciliation: a scheduled comparison of won quotes, sent orders and acknowledged orders by count and value, with exceptions in a view someone owns, instead of a spreadsheet someone maintains.
• Inbound data: product, customer and credit status from the ERP arrive through the same pattern in reverse, so the price book has one source.
• Desktop flow automation of the ERP screens only as a last resort, when there is no table and no file interface at all.

Where does Solzet work, and where does the ERP team take over?

Solzet delivers the CRM side and the integration: Dynamics 365 Sales configuration, the pricing and approval layer, Power Automate flows, the staging or file contract, acknowledgement and reconciliation. We do not implement or modify Dynamics 365 Finance, Business Central, Dynamics NAV, Finance and Operations or any other ERP. Where the ERP needs a new import routine or a staging table on its side, we specify the contract and work alongside your ERP team or vendor who builds it. The same applies to a custom application: we build the quoting system and its integration, not the ERP.

How do you cut over from the spreadsheet in phases?

A big bang switch from a spreadsheet many people rely on is the riskiest possible cutover. Phasing keeps the business trading while the new process proves itself, and it has one firm rule: every phase ends with something in the spreadsheet becoming read-only, so double entry never becomes permanent.

• Phase 1, inventory the workbook: every tab, formula, macro, hidden column and unwritten rule, turned into written pricing and approval rules that compliance signs off.
• Phase 2, catalogue and price lists: products and price lists loaded into Dynamics 365 and reconciled against the workbook; the price tabs then become read-only and pricing changes happen only in the system.
• Phase 3, pilot quoting: one team quotes in Dynamics 365 with approvals live, while totals are compared against the workbook for a short, agreed parallel period.
• Phase 4, all teams quoting: remaining teams move over in waves with training; new quotes in the spreadsheet stop on an announced date.
• Phase 5, orders to the ERP: the staging or file integration replaces re-keying, with reconciliation running from the first day.
• Phase 6, retire the workbook: open quotes migrated or allowed to expire, the file archived read-only as historical evidence, and the audit trail from then on lives in the platform.

What should you decide before choosing a platform?

A short discovery answers these questions, and they decide the platform far more reliably than a feature list. If you want a second opinion on the answers, the Dynamics 365 Sales implementation and custom CRM development pages describe how each engagement runs.

• Is your price looked up from a list and discounted, or calculated from a model?
• How many people quote, how many only view or approve, and are any of them outside the organization?
• Which controls has compliance actually asked for, and in what form must the evidence be produced?
• What can the ERP accept today: a table, a file, or only a screen?
• Do sellers need a CRM around the quote, or only a governed quoting workflow?
• Where must the data be hosted?