Entitlements and Contract Hour Packages in Dynamics 365 Without Monthly Billing Disputes

Why do contract hour packages in Dynamics 365 end in monthly billing disputes?

Because the number on the invoice cannot be traced back to the work. A customer buys a package of support hours or cases, the service team works cases, and at month end someone reads a remaining balance and bills the difference. When the customer asks which cases used their hours, the answer depends on settings nobody documented and adjustments nobody recorded.

The usual causes are the same across services businesses: one entitlement edited at every renewal so its totals mix two contract periods, cases attached to the wrong entitlement or to none, hours taken from whatever was typed when resolving instead of from recorded time, reopened cases whose deductions nobody checked, and remaining terms corrected by hand to match a spreadsheet. None of these is a product defect. They are modelling and process gaps, and they are fixable before the next invoice run. If the dispute is about response or resolution time commitments rather than hours used, start with our guide to SLA timers and billing from SLA reports.

How do Dynamics 365 entitlements decrement by cases or by hours?

An entitlement is a record for a customer, active between a start and an end date, holding a number of support terms. A few fields decide all of its behaviour, so write down the chosen value for each and the reason.

• Entitlement templates hold the settings of a package, so a new entitlement for a customer starts from the package rather than from memory.
• A case only decrements the entitlement set in its entitlement lookup, so how that lookup is filled matters as much as the entitlement itself.
• The older Contracts feature in Customer Service is deprecated in favour of entitlements; check current Microsoft documentation if you still have contract records.

How should entitlements be modelled for two hundred contracts with different packages?

One entitlement per customer per contract term, generated from one template per package, never edited into the next term. Renewal creates a new entitlement with new dates and totals; the old one expires with its history intact. That single rule removes a whole class of disputes, because every deduction belongs to exactly one contract term and can be listed against it.

• Build a template for each package you sell, with allocation type, decrease remaining on, channel terms, restrict case creation and SLA already set. Packages that differ only in size can share a template with the total set at creation.
• Add a contract reference column to the entitlement and an alternate key on contract reference plus term start, so a generation flow or integration cannot create the same term twice.
• Generate entitlements from the signed contract data with a Power Automate flow, whether that data sits in Dynamics 365 or arrives from the system that holds contracts, instead of creating two hundred records by hand.
• Fill the entitlement on each case automatically from the customer, product and date, and make the lookup read-only for most agents, so cases do not land on the wrong term.
• Decide the overage rule per package: restrict case creation, or allow work and bill the excess. If excess is billable, record it explicitly rather than letting it vanish at zero.
• Keep top-ups, rollover of unused hours and mid-term changes as documented, approved events. If they are frequent, read the section on when a custom hours ledger is simpler.

What happens to remaining terms when a case is reopened or cancelled?

This is where disputes hide, so establish the behaviour by testing rather than assuming. Reactivating a resolved case is expected to credit the deducted terms back to the entitlement, and resolving it again deducts again based on the new resolution. For cases that decrement on creation, whether cancelling the case returns the term is exactly the kind of behaviour that must be confirmed in your version. Check current Microsoft documentation, then prove it in a sandbox before you design billing around it.

• Test each package template with scripted scenarios: create, resolve, reactivate, resolve again with different time, cancel before resolution, cancel after reactivation, and a case moved to another entitlement.
• Record remaining terms before and after each step, and keep the results with the date and version tested, so a later release can be checked against them.
• Turn on auditing for remaining terms on the entitlement and for case status, so every change to a balance is traceable to an event.
• Where the platform's behaviour does not match the contract, for example cancelled cases should cost nothing, implement the rule explicitly and visibly rather than correcting balances by hand.
• Never edit remaining terms manually to make a report match. Every manual change is a future dispute with no evidence behind it.

How do you make the hours deducted on case resolution defensible?

Make the time come from records the customer can see, not from a number typed at the end. For an hours entitlement that decreases on resolution, the deduction comes from the time recorded when the case is resolved in the Resolve Case dialog. Confirm in your version whether that is the total or the billable time field, test it, and then make sure the value agents submit is derived from real work.

Agree the rule once and apply it everywhere: which activities count (calls, emails, remote sessions, visits), whether internal notes and travel count, rounding per activity or per case, and a minimum charge if the contract has one. Then record time where the work happens, on activities or time entries against the case, so the resolution time can be checked against a sum of dated entries. A case whose resolution time differs from its recorded activity time should be flagged for review before the statement goes out, not discovered by the customer.

How do you show the remaining balance to agents and customers?

Show the same number to both, from the same record, with the list of cases behind it. Disputes shrink when the customer can see the balance falling during the month instead of meeting it on an invoice.

• On the case form, show the entitlement with a quick view of its end date, total terms and remaining terms, so an agent sees a low balance before starting work.
• Warn agents when remaining terms fall below a threshold agreed per package, and tell the account owner, so renewal or top-up conversations happen before the allowance runs out.
• On a Power Pages customer portal, list the customer's active entitlements with remaining terms and the resolved cases that used them. Scope table permissions to the customer's own account carefully; the ways that goes wrong are covered in our Power Pages table permissions guide.
• Send a monthly usage statement by email listing each case, date, resolution time and running balance, generated from the same data as the invoice.

How do you rebuild the disputed months from case and time records?

Rebuild each disputed month from the underlying events, not from the entitlement's current balance, which has been overwritten many times since.

• Fix the scope: the customer, the entitlement terms in dispute, and the invoice periods, and freeze an export of the invoices as issued.
• Extract every case linked to those entitlements with creation, resolution, reactivation and cancellation dates from case status audit history, including cases later moved to another entitlement.
• For each case, take the latest completed case resolution and its recorded time, and check what happened to earlier resolutions after a reactivation, so reopened cases are counted once.
• Sum time entries or activity durations per case for the same period, and list every case where they disagree with the resolution time.
• Apply the contract rules explicitly (counted activities, rounding, minimums, cancelled cases) to produce the usage that should have been billed per month.
• Compare with what was invoiced, month by month, and produce a statement of differences with the cases behind each one for the account manager and finance to agree with the customer.
• Where audit history is missing for a period, say so on the statement rather than filling the gap with assumptions; retention and audit gaps are covered in our audit trail guide.

What should change so the next invoice is defensible without manual effort?

Turn the rebuild into the monthly process. At month end, a scheduled flow writes a usage statement record per entitlement: opening balance, each case with its date and deducted terms, adjustments with approvals, and closing balance. The statement is a snapshot that is never recalculated, so the figures sent to the customer in March still read the same in September.

Before the statement is issued, automated checks flag the exceptions a person should look at: cases without an entitlement for customers who have one, resolution time that differs from recorded time, reactivated or cancelled cases in the month, entitlements with a remaining balance changed outside a case event, and closing balances that do not equal the opening balance less the listed deductions. The invoice line for each contract reads from the statement, and the customer's statement email and portal show the same lines. Solzet does not implement finance or invoicing systems; the statement is what your billing process consumes. If wrong invoices have already gone out, the sizing and correction method is in our guide to fixing the system behind billing errors.

When is a custom hours ledger simpler than entitlements?

Entitlements hold a balance and deduct from it on case events. They do not keep their own list of transactions, and they count per case. When the contract is really about time recorded across many pieces of work, a small custom ledger is often simpler: a contract term table and an append-only ledger of dated debit and credit entries, each pointing to the time entry, case or approved adjustment behind it. The balance is the sum of the entries, and the statement is a filtered list. The design and locking of an append-only table in Dataverse is covered in our allocation ledger guide.

Should contract hour tracking stay in Dynamics 365 or move to a custom build?

For services businesses already running Dynamics 365 Customer Service, keep it there: entitlements, cases, time and the customer portal share one customer record, and the SLA applied through the entitlement sits beside the hours it measures. The choice that matters is between entitlements and a custom hours ledger inside Dataverse, which depends on your contracts rather than on the platform.

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. Where the business is mainly contract, time and billing administration with a light support desk, and Microsoft licensing does not fit the user count, a custom-built CRM on React, Node.js, PostgreSQL or .NET can hold the contract terms, ledger and customer statements under your own control.

How does Solzet help end contract hour billing disputes?

We start with the disputes themselves: a handful of disputed months rebuilt from case, resolution and time records, which shows which settings and habits produced the differences. Then we test entitlement behaviour for each package in a sandbox, restructure entitlements to one per customer per term from templates, automate their generation from contract data, surface balances to agents and customers, and put the monthly statement and exception checks in place, or build a custom hours ledger where the contracts need one.

The work is done by senior consultants and full-stack developers delivering remotely from Yerevan, Armenia, with 8+ years of Dynamics 365 Customer Engagement and Power Platform work, directly for your team or white-label for Microsoft partners. Wider case management, routing, SLA and knowledge design sits with our Dynamics 365 Customer Service implementation service.