Built to bill: how a Dynamics 365 platform learned to think like a law firm

Legal services run on an unusual economic model. Value is created hour by hour, often months before it is ever invoiced, and every one of those hours has to survive a review before it counts as revenue. Industry benchmarks put the average firm's realization rate, the share of billable work that actually reaches an invoice, at around 88 percent. That means roughly 12 cents of every dollar of legal work performed never makes it onto a client bill. The same research points to a lag of more than three months between work done and cash collected. 

That gap explains why legal billing software carries so much weight. Every billable hour has to land against the right matter, at the correct rate, with taxes applied accurately. Trust accounts have to reconcile to the cent. Corporate clients with in-house legal departments expect their bills in the standardized LEDES format that their outside counsel guidelines require. Get any part of that wrong and a firm either under-bills its own work or fails an audit from a client's finance department. 

Our client wanted a system covering the full lifecycle of a firm's financial operations, well beyond anything a Dynamics 365 add-on could carry. On the matter side, the system had to track three things: who the client is, what the case is, and what work was done on it. 'Matters' is the legal industry's term for a case or engagement, it's the object every legal matter management system is built around. Time entries, flat-fee services, and other costs all roll up from there into a monthly invoice. Those invoices generate as PDFs, as consolidated bills across multiple matters, or as LEDES files for e-billing. On the accounting side, it meant a parallel system for payments, allocations, disbursements, credits, write-offs, bank deposits, rates, taxes, and transfers between accounts. This is the kind of ledger-level detail that trust-accounting rules demand and that a general-purpose CRM was never built to handle. 

Building all of that on Dynamics 365 created a second, quieter problem. How do you ship a single evolving product to more than twenty separate client organizations, each running its own Dynamics 365 environment, without turning every release into a bespoke migration? And once clients start asking for firm-specific work on top of that shared core, a custom integration here, a Power BI reporting suite there, how do you keep those one-off requests from slowly forking the product into twenty incompatible versions? 

We joined the engagement as a third-party development partner and collaborated across both sides of that challenge over several years. 

The first side was product engineering. We worked in three-week sprints, pulling functionality from a shared backlog: one sprint on the billing engine, the next extending the accounting module, others spent hardening the matter and invoicing workflows. Each sprint's output went through a testing cycle, then rolled out to every client organization at once. To make that possible, we helped build a LinqPad-based deployment script that installed the updated solution across all live Dynamics 365 tenants in parallel threads, with no practical limit on how many client environments a single pass could update. What had been a two-day deployment, spread across Saturday and Sunday and entirely outside business hours, became a single four-hour window on a Saturday morning, with all twenty-plus tenants updated in one run instead of one at a time. 

The second side was implementation and support, and it ran on a different rhythm. Each new client got its own sandbox and production environment, plus a dedicated Azure DevOps project to hold that firm's specific customizations, layered cleanly on top of the shared base solution rather than forked from it. Here the work shifted from sprints to a kanban flow, because every firm's priorities were different. One client might need a batch of new plugins or a third-party integration. Another might focus entirely on custom reports and Power BI dashboards. Triaging that constantly shifting backlog took a different discipline than product sprints, closer to a support desk than a release train, but still shaping production-quality Dynamics 365 work: C# plugins and workflow activities, form logic in JavaScript and TypeScript, and integrations that had to coexist with a base product still being actively developed underneath them. 

That combination of one core moving forward together and customizations layered on top instead of forked off is what has kept the client's platform serving more than 20 law firms with materially different needs, for years, without splintering into 20 unmaintainable versions. A four-hour deployment window replaced what used to eat an entire weekend and changed what we could realistically ship. The product now sustains at least four releases a year, a cadence the old rollout process could not have supported, so every client gets product improvements on a predictable schedule instead of waiting on a slow, manually managed upgrade. And the per-client DevOps and kanban model meant firms with urgent, specific needs, like a missing integration or a compliance-driven report, could get them addressed without waiting for the next full product release. 

For the firms themselves, the win maps directly onto the industry's own numbers. Software that captures billable work against the right matter and turns it into an accurate invoice, with LEDES exports that satisfy corporate billing rules, closes the gap between hours worked and revenue collected. In an industry where that gap routinely costs firms a meaningful share of billable work, a billing engine that gets the details right adds straight back to what a firm actually collects. 

It doesn’t stop at any one firm’s books. Corporate legal departments increasingly require outside counsel to bill electronically and in standard formats so they can audit legal spend. A platform that produces clean LEDES data on the first try reduces friction on both sides of that relationship, and lets firms spend less time on billing administration and more on the work their clients hired them for. 

Five years in, this isn't a project anymore. It's an ecosystem: one core codebase, 20-plus live client environments, two delivery rhythms, and a business model with almost no tolerance for billing errors. If your Dynamics 365 platform is straining under the weight of serving multiple clients from one codebase, or your billing logic is more fragile than your revenue can afford, it is worth a conversation about what a more deliberate architecture could do.