A finance director at a mid-size systems integrator called her Microsoft partner last week with a simple question: can we finally bill our managed services retainers automatically instead of re-keying the same fixed-fee lines into a project invoice every month? She had just read a Message Center notice about Project Operations subscription billing and wanted to know how soon her team could stop doing this by hand. The answer she got was more complicated than the announcement suggested, and it is worth walking through, because the gap between what is generally available today and what is entering preview later this month will shape a real budgeting decision for a lot of professional services firms this quarter.
Project Operations Subscription Billing: Two Announcements, Not One
There are actually two separate pieces of functionality connected to this topic, and conflating them is the easiest way to make a bad planning decision. The first, “enable project fee journals to support subscription billing,” has been generally available since Dynamics 365 Finance version 10.0.46, released in October 2025. It lets a project generate a billing schedule through the Subscription Billing module, using Project Fee Journal as the invoice transaction type instead of a standard project invoice. The second, tracked in Microsoft’s Message Center as MC1472430 and titled simply “support subscription billing for Project Operations,” entered public preview on September 30, 2026. It promises recurring billing on flexible cadences, tiered pricing models, subscription hold and termination handling, and refund management, described by Microsoft as reducing manual intervention in recurring invoicing. Only the first one exists in production today. The second is a preview, and previews change shape before they reach general availability.
How the Fee-Journal Mechanism Actually Works
For the capability that is live now, the workflow starts on the project record itself. From Project management and accounting, a user creates a new billing schedule directly from the project, and the system automatically populates the customer account, the project ID, and the funding source. The invoice transaction type gets set to Project Fee Journal rather than Sales Order, which determines how the billing schedule lines behave. Each line carries a fee category, a unit price, and the usual tax fields, but it flows through work-in-progress and accrual postings before it ever becomes a customer-facing invoice.
That sequencing matters more than it sounds. Rather than posting a project invoice the moment work is recorded, the system books WIP and accrual entries through the fee transaction first, then generates the actual invoice on a schedule, whether monthly, quarterly, or however the contract is structured. A firm can choose from three posting behaviors: generate the fee journal only and create invoices manually later, generate the journal and stop at an invoice proposal for review, or post the invoice automatically in one step. That range gives controllers real choice over how much human review sits between recognized revenue and a document that goes out to the client.
The catch, and it is a significant one, is that this fee-journal path is only available for Project Operations deployments that run on the Finance and Operations platform, what Microsoft’s own documentation refers to as Project Operations for manufacturing. A standalone deployment of Project Operations, the version many services firms chose specifically because it does not require standing up the full Finance and Operations stack, cannot use it. If your organization licensed Project Operations to avoid exactly that complexity, the subscription billing capability that shipped last October simply is not on your platform, no matter how current your update cadence is.
Why the Deployment Distinction Is the Actual Decision Point
This is where the finance director’s original question gets harder to answer cleanly. If her firm runs the Finance-integrated deployment, the fee-journal mechanism is already available, and the work is largely configuration: enabling the relevant features in Feature management, setting project stage rules to trigger billing schedule creation automatically, and deciding which of the three posting behaviors matches her team’s risk tolerance for unattended invoicing. If her firm runs standalone Project Operations, the near-term answer is to watch the MC1472430 preview closely rather than assume it will simply extend the same mechanism to her platform.
Microsoft’s release documentation for 2026 wave one describes the fee-journal capability specifically in the context of manufacturing deployments, and nothing in the public preview announcement confirms that the broader recurring billing framework will be deployment-agnostic once it reaches general availability. Firms that commit new client contracts to a subscription billing structure on the assumption that Project Operations will automate it end to end, without first confirming which platform variant they run, are setting up a manual workaround they did not budget for. That is an expensive mistake to discover six months into a new retainer agreement.
There is a real financial argument for making this move regardless of which deployment a firm is on, and it has less to do with saving a few hours of invoice preparation than with getting revenue recognition right. Because the fee-journal mechanism books WIP and accrual entries ahead of the customer invoice, it gives finance teams a documented, systematic separation between when value is delivered and when cash is billed. That separation is exactly what supports ASC 606 and IFRS 15 compliance for recognizing revenue independent of billing milestones. A firm still reconciling that gap manually in a spreadsheet, project by project, is carrying audit exposure that this feature is specifically built to remove. That argument for prioritizing the upgrade path is stronger than “we bill retainers and want less manual work,” even though the manual-work complaint is usually what starts the conversation.
What to Check Before the Next Contract Renewal Cycle
Before signing a new managed services or retainer agreement on the assumption that Project Operations will handle the billing automatically, confirm three things. First, identify which Project Operations deployment your organization actually runs, since the terminology in vendor conversations, and even in some Microsoft documentation, does not always make the distinction obvious to someone outside the implementation team. Second, if you are on the Finance-integrated deployment, treat this as a configuration and change-management project rather than a licensing question. Feature management settings, project stage rules, and the choice of posting behavior all need to be worked through with whoever owns your Dynamics 365 Finance environment before the first live billing schedule goes into production.
Third, if you are on standalone Project Operations, do not build a client-facing commitment around a preview feature. Track the Message Center entry, ask your partner directly whether the general availability scope will include your deployment type, and keep the manual process in place as a fallback until that answer comes back in writing rather than inferred from a roadmap post. Preview features are, by definition, subject to change, and a contract term written around one is a liability if the feature narrows or slips before it ships broadly.
The subscription billing announcement is a genuine step forward for firms trying to move recurring engagements off manual invoicing, and the fee-journal mechanism that already exists proves the underlying accounting model works in production. What it is not, yet, is a platform-wide capability every Project Operations customer can turn on this quarter. Firms that treat the distinction seriously now will spend less time unwinding a contract structure that outran their tooling. We have walked several clients through exactly this kind of platform-versus-roadmap gap during Project Operations rollouts, and the pattern holds: the tooling question is almost always simpler to answer once the deployment type is confirmed first, before a single retainer contract gets rewritten around a capability that may not yet apply to it.
#ProjectOperations #SubscriptionBilling #RevenueRecognition #ProfessionalServicesFinance #DynamicsFinanceOps #ERPGovernance