What Microsoft announced
The AI at Work roadmap entry, ID 570862, is titled "Dynamics 365 Field Service: Support multiple payers across Work Order lines." Microsoft describes a common problem: one field visit can have more than one payer. The customer may pay for the main service while a warranty provider, manufacturer, partner or other eligible billing customer pays for specific products or services from the same visit.
The feature would set billing responsibility on each Work Order line instead of making every transaction on a work order follow one payer.
Here is what the roadmap entry says:
| Attribute | Roadmap value |
|---|---|
| Roadmap ID | 570862 |
| Product | Dynamics 365 Field Service |
| Status | In development |
| Platform | Web |
| Release ring | General Availability |
| Cloud instance | Worldwide (Standard Multi-Tenant) |
| Target GA | November 2026 |
Microsoft's roadmap dates are estimates, and the company says all roadmap information can change. As of now, the feature is in development, not shipped.
Section summary: Line-level payer assignment is planned for Field Service on the web, with November 2026 as the general availability target. Nothing has shipped yet.
Why this matters: how billing works today
Today, each work order has one billing context. Microsoft's documentation says posting a work order generates Invoices for used work order products and services for the billing account of the work order. The usual sequence is that a back-office worker reviews the completed work order and starts the billing process. They change the work order system status to Posted. If products and services were used, this status triggers Invoice generation, depending on the system's configuration in Field Service Settings.
The Billing Account field matters most here. Microsoft's account guidance says the billing account represents the account that receives invoices for the work provided. It is usually a shared account for multiple service accounts that belong to a central organization. For example, a wine producer corporation owns several vineyards. Each vineyard is a service account. The corporation is the billing account. The billing account also affects pricing: if you specify a billing account, work orders use the price list in the billing account record.
That setup works when one organization owns the whole bill. The vineyard example has one payer for many sites. The roadmap feature covers the opposite case: one site and one visit with several payers.
In the work order form, the Financial card contains all the financial information for a work order, such as the billing account, whether the work order is taxable, the price list to apply, and the not-to-exceed amount, if applicable. These are all set for the whole work order, which is why a warranty-plus-customer job has usually needed workarounds.
The line items themselves are simple. A product is an item a field technician might record while completing a work order that the client might be billed. A service is work that a field technician performs and might bill the client for. Service is measured in time duration. Products and services are the natural place to split payers, and the roadmap targets exactly those lines.
Section summary: Today one billing account per work order receives the invoice for all used products and services. The roadmap feature would break that one-payer assumption at the line level.
Real-world scenarios this could address
The roadmap entry names warranty providers, manufacturers, partners and other eligible billing customers. Some typical jobs, as illustrations rather than confirmed workflows:
- Warranty repairs: An HVAC technician replaces a failed compressor under manufacturer warranty, and the homeowner pays for the diagnostic visit and labor outside the warranty terms.
- OEM service networks: A medical device service provider does a repair where the manufacturer covers certain parts and the hospital pays for everything else.
- Partner-funded work: A channel partner funds part of an installation and the end customer pays for add-ons done on the same visit.
Without line-level payers, these jobs tend to end up as split work orders, manual invoice edits after posting, or custom plug-ins and integrations. Each of those adds admin work and more room for billing mistakes. In theory, putting the payer on the line keeps one visit as one work order.
What this feature is not
Microsoft already has other features that deal with multiple parties. They are easy to confuse with this one:
- Project Operations task-based billing. The Field Service and Project Operations integration supports multiple billers. Different project tasks map to different project contract lines and customers, and work order transactions resolve through project, task and transaction class. That is a project-based financial setup and requires Project Operations. The roadmap item describes payer selection on ordinary Work Order lines.
- Entitlements. Work order entitlements can apply price lists, discounts, or free products and services based on criteria like billing account, customer asset or incident type. When several entitlements apply, the system picks one by priority. Entitlements change the price, not who pays, so they don't already do what this feature promises.
- Parent/child work orders. Some teams split jobs into related work orders to separate billing. That is a workaround, and the new capability appears aimed at removing the need for it.
What Microsoft hasn't said yet
The roadmap entry is short. Microsoft has not published:
- Which payer types count as "eligible," or how eligibility is configured
- Whether the feature covers only products and services, or other line types too
- How invoice generation changes when one work order has several payers (one invoice per payer, or something else)
- How it works with price lists, entitlements, tax settings and not-to-exceed amounts
- Whether the mobile app supports it (the roadmap lists Web only)
- Licensing, feature switches, or effects on the Business Central and Finance integrations
Any article that confidently answers these questions today is guessing. Wait for Microsoft's release documentation.
Guidance for administrators and partners
Some practical steps before November 2026:
- List your workarounds. Find every plug-in, flow, split-work-order pattern or manual invoice correction you use now to handle mixed payers. These are the parts most likely to conflict with, or be replaced by, the native feature.
- Check downstream integrations. If Field Service invoices feed Business Central, Finance or another ERP, find out what those connectors assume about one billing account per work order.
- Plan sandbox testing. When the feature reaches your environment, test it in a non-production instance first, especially if you have custom logic on work order product or service records.
- Keep finance involved. Line-level payers affect accounts receivable, warranty claim reconciliation and revenue reporting, not just the work order form.
- Treat the date as provisional. Roadmap targets slip. Don't schedule a go-live around November 2026 until Microsoft confirms it has shipped.
The bigger picture
Much of Microsoft's recent Dynamics 365 marketing has focused on Copilot and agents. This roadmap item is a plain billing fix, the kind of change that doesn't demo well but can matter a lot to people who run service operations. Service companies with warranty-heavy businesses have been building their own versions of this for years.
The question is whether Microsoft's version will handle real invoicing, including per-payer invoices, tax and ERP sync, or just add a payer field and leave the rest to partners. We'll know once the documentation is published.
Bottom line: Line-level payers could remove a long-standing annoyance for Field Service teams billing warranty and partner-funded work, but the details are still unknown.