Can I keep Dynamics 365 or Navision if I adopt a CSP platform?

Yes. A CSP platform built as a provisioning layer connects to your existing CRM and ERP instead of replacing them. Microsoft's own documentation describes the Partner Center REST API as a way for CSP partners to integrate their existing CRM or billing software with Microsoft's systems for customer accounts, orders, subscriptions, and support. In that model, Dynamics 365 or Navision keeps customer data, quotes, invoicing, and accounting, while the provisioning layer handles Partner Center orders, cancellation deadlines, and priced invoice line items. The integration runs through a REST API: the CRM places orders and keeps its own identifiers on each record, and the ERP reads priced invoice line items. Check that the platform publishes a documented public API before you commit.

What is the difference between a CSP control panel and a provisioning layer?

A CSP control panel is often sold as the place where the whole CSP business runs, including customers, pricing, and invoicing, which can overlap with systems a partner already owns. A provisioning layer is narrower: it owns every transaction between the partner and Partner Center and makes results available to the partner's CRM and ERP through an API. Microsoft uses the term Control Panel Vendor (CPV) for an independent software vendor that builds applications to help CSP partners integrate their systems with Partner Center APIs. Note that Microsoft has temporarily paused new CPV enrollments, which is one more reason partners increasingly rely on existing platforms rather than building their own.

Why not build a direct integration between my ERP and Partner Center?

You can, but you inherit every change Microsoft makes. Since April 1, 2026, all App+User calls to Partner Center APIs must use multifactor authentication through the Secure Application Model. Billed and unbilled reconciliation data now comes from asynchronous export APIs on Microsoft Graph that require the PartnerBilling.Read.All permission, not from the Partner Center API host. Webhook events such as Subscription Updated can arrive up to 48 hours after the change. A homegrown connector has to track all of this, plus NCE rules, indefinitely. For most Direct Bill partners, that maintenance burden outweighs the cost of an API-first provisioning layer that absorbs these changes for them.

How does the NCE seven-day window affect CRM and ERP integration?

It sets a hard deadline that batch integrations can miss. Under the new commerce experience, license quantities can only be reduced within seven days of purchase or renewal, with a full refund if the cancellation happens within 24 hours and a prorated refund after that. After seven days, no refund is available and the partner pays for the full term. If your CRM only syncs with Partner Center overnight or weekly, a correction requested late in the window can land after it closes. A provisioning layer that submits changes as soon as they are requested, and exposes each subscription's cancellation deadline through its API, removes that timing risk regardless of how often your CRM syncs.

What should a CSP platform send back to my ERP?

At minimum, your ERP should receive reconciled billing data it can post without manual rework: billed line items per customer, the pricing and margin rules you apply, and any credits or adjustments. Microsoft publishes billed and unbilled reconciliation data through the partner billing API on Microsoft Graph, and daily-rated usage normally takes 24 hours to appear. A provisioning layer should retrieve that data, apply your commercial rules, and make the priced line items available through an API your ERP can read, carrying your own customer and subscription identifiers. If a platform only offers dashboards and no programmatic access, your ERP will end up depending on spreadsheets, which defeats the point of integration.

Can a CSP Platform Integrate With Your CRM and ERP?

CloudCockpit Team | Published September 7, 2026

Yes. A CSP platform should plug into the CRM and ERP you already run, not replace them, and Microsoft's own Partner Center API was designed on exactly that assumption. What most mature Direct Bill partners are missing is not a new system of record but a provisioning layer: the piece that sits between Partner Center and their business systems,executes orders and subscription changes, keeps every cancellation deadline visible, and makes clean, priced billing data available to the CRM and ERP through an API. This article explains what that layer does, what should stay where it is, and what to check before you pick one.

Does Adopting a CSP Platform Mean Replacing Your CRM or ERP?

No. Replacing a working CRM or ERP to automate CSP operations solves the wrong problem and throws away years of configuration, customer data, and finance process.

Microsoft describes the Partner Center REST API as a way for CSP partners to "integrate their existing CRM or billing software with the Microsoft systems that manage customer accounts, place orders, manage subscriptions, and handle support requests." The integration model is built into the program itself: your systems stay, and Partner Center connects to them.

In a recent conversation, a long-established Direct Bill partner put the fear plainly: "We don't want to throw away all the job we already done." That partner had years of pricing rules, customer records, and invoicing logic built into its CRM and ERP stack, and every CSP platform it had evaluated before seemed to assume a fresh start.

CloudCockpit note: This is the objection we hear most from mature partners, and it is a reasonable one. A CRM or ERP that has run the business for a decade encodes decisions nobody has written down anywhere else. Any platform that requires migrating all of it before the first order goes through is asking the partner to take on a project risk that has nothing to do with CSP.

For a Direct Bill partner, the practical question is not "which system replaces ours" but "which layer connects ours to Partner Center safely."

What Is a Provisioning Layer in Microsoft CSP?

A provisioning layer is the system that owns every transaction between your business and Partner Center, and nothing more.

It takes an order or change that originates in your CRM (or a portal, or a sales rep), validates it against Microsoft's commerce rules, executes it through the Partner Center API, and reports the result back. It then pulls billing and reconciliation data from Microsoft and hands it to your ERP in a shape your finance team can post.

A provisioning layer typically handles:

Order execution: creating customers, placing orders, and changing license quantities through Partner Center.
NCE rule enforcement: knowing, for every subscription, the date until which it can still be cancelled.
Lifecycle events: keeping subscription status, end dates, and renewal settings current and readable by downstream systems..
Pricing and margin: applying your margin rules per reseller, per customer, or per subscription on top of Microsoft's cost.
Billing data for finance: exposing priced, per-customer invoice line items that the ERP can read for invoicing and accounting.

The distinction matters because a provisioning layer does not need to become your system of record for customers, quotes, or the general ledger. It needs to be the system of record for what Microsoft thinks you bought.

Which Jobs Should Stay in Your CRM and ERP?

Anything your business already does well outside the Microsoft transaction should stay exactly where it is.

A clean split for a Direct Bill partner usually looks like this:

Stays in the CRM: customer master data, opportunities and quotes, account ownership, contract terms, and sales pipeline reporting.
Stays in the ERP: customer invoicing, tax, the general ledger, credit control, and collections.
Moves to the provisioning layer: Partner Center orders and quantity changes, subscription cancellation deadlines, priced invoice line items, and per-customer margin calculation.

The line to draw is simple: if Microsoft's rules govern it, the provisioning layer owns it. If your own commercial or accounting rules govern it, your existing systems keep it.

For a partner running a Dynamics 365 CRM next to an older Navision ERP, for example, this split means neither system has to learn Partner Center. They only have to exchange data with the layer that already speaks it.

Why Is a Direct Partner Center Integration Harder Than It Looks?

Because Partner Center is a moving target, and a homegrown connector has to keep up with every change Microsoft ships.

Some of the changes a do-it-yourself integration has had to absorb recently:

MFA enforcement on API calls: beginning April 1, 2026, all App+User usage of Partner Center APIs enforces multifactor authentication through the Secure Application Model. Connectors that stored plain credentials or skipped the consent flow stop working.
Billing data moved to Microsoft Graph: the current billed and unbilled reconciliation APIs are asynchronous exports hosted on Microsoft Graph, not the Partner Center API host, and they require the PartnerBilling.Read.All permission.
Event timing is not real time: Microsoft documents a delay of up to 48 hours between a subscription change and the Subscription Updated webhook event, and daily-rated usage normally takes 24 hours to appear.
The NCE seven-day window is unforgiving license quantities can only be reduced within seven days of purchase or renewal, with a full refund only within the first 24 hours and no refund after seven days.

CloudCockpit note: The seven-day window is where CRM-first integrations most often fail quietly. If the CRM syncs with Partner Center on a nightly or weekly batch, a correction requested on day six can land after the window has closed, and the partner pays for the full term. The provisioning layer has to act on the Partner Center side immediately, even if the CRM only learns about it later.

Each of these is manageable on its own. Maintaining all of them, indefinitely, inside a connector your team built for a different purpose is where the operational risk accumulates.

How Does API-First Integration Work in Practice?

API-first integration means your existing systems talk to the provisioning layer through documented interfaces, and the provisioning layer handles Partner Center.

A typical flow with CloudCockpit looks like this:

The order originates where it always has: a quote closes in the CRM, and the CRM calls the CloudCockpit API to create the order, with quantity, term, billing frequency, auto-renew, and the PO number it already tracks.
Your identifiers travel with the record: customers, resellers, and subscriptions each carry an internal identifier (up to 255 characters on the customer relationship), so the CRM's own account and contract IDs stay attached to the Microsoft side.
Every change is traceable: subscription updates and cancellations are processed asynchronously, and the audit log records each operation with its status (processing, succeeded, or failed), its origin (a user, the API, or the system), and an optional correlation ID your integration sets on the request.
Deadlines are readable, not guessed: every subscription exposes its cancellation deadline (cancellationAllowedUntil), end date, and renewal settings, and a single endpoint lists subscription end dates for coterminosity.
Finance reads priced line items: the ERP retrieves invoice line items through the API, paginated up to 2,000 items per page, each with customer and reseller prices, applied margin rules, taxes, and the same internal identifiers and PO number.

Nothing in this flow asks the CRM or ERP to change what it is. It asks them to send and receive data through an API, which is the same integration pattern Microsoft designed Partner Center around.

For a Direct Bill partner, the result is automation of the Microsoft side without a migration project on the business side.

What Should a Direct Bill Partner Check Before Choosing a Provisioning Layer?

Check whether the platform integrates on your terms or expects you to adopt its terms.

Five questions separate a provisioning layer from a replacement in disguise:

Is the API public and documented?

If integration depends on a professional services engagement to discover endpoints, your roadmap depends on theirs.

Does it push events, or only accept requests?

Without webhooks or equivalent events, your CRM has to poll, and polling is how data drifts.

Can billing data leave in a format your ERP can post?

Reconciled exports matter more than dashboards for a finance team that already has its own tools.

Does it enforce NCE rules at execution time?

Validation of the seven-day window should happen before an order is placed, not in a report afterwards.

Does it keep up with Partner Center changes for you?

MFA enforcement, the move to Graph billing APIs, and new webhook events are exactly the changes a platform should absorb so your team doesn't have to.

CloudCockpit note: A useful test during evaluation is to ask the vendor what happens to your CRM on day one. If the answer involves exporting your customers into their system before anything else can happen, you are looking at a replacement, whatever the sales deck calls it.

The Bottom Line

You do not need to replace your CRM or ERP to automate Microsoft CSP. You need a provisioning layer that owns the Partner Center side, makes every cancellation deadline visible, and exposes clean, priced data through an API the systems your business already trusts can read. With MFA now enforced on all App+User Partner Center API calls since April 1, 2026, and billing data served through Microsoft Graph export APIs, the cost of maintaining a homegrown connector keeps rising. Expect the partners who scale fastest over the next few fiscal years to be the ones who stopped treating CSP automation as a system replacement and started treating it as an integration layer.

Sources

What are the Partner Center REST APIs?: the Partner Center REST API helps CSP partners integrate their existing CRM or billing software with Microsoft's systems for accounts, orders, subscriptions, and support.
Enroll as a Control Panel Vendor: definition of a Control Panel Vendor, and notice that CPV enrollments are temporarily paused.
Partner Center authentication: beginning April 1, 2026, all App+User usage of Partner Center APIs enforces MFA.
Billed invoice reconciliation API v2 (GA): the reconciliation API is hosted on Microsoft Graph, not the Partner Center API host.
Partner Center webhooks: webhook registration and supported events, including the up to 48-hour delay on Subscription Updated.
Cancellation policy for the new commerce experience: prorated refund within seven calendar days for license-based subscriptions.
Billing scenarios for one-time and recurring purchases in NCE: full refund within 24 hours, prorated refund within seven days, no refund after seven days.
Change the quantity of licenses in a customer subscription: quantity reductions only within seven days of purchase or renewal, and the refundableQuantity field.
CloudCockpit API documentation: Introduction: public REST API, version v1, base URL api.cloudcockpit.com, downloadable OpenAPI specification.
CloudCockpit API: Getting Started: API Access is created by CSPs with the required permission in the portal settings; resellers request it from their CSP.
CloudCockpit API: Authentication Guide: OAuth 2.0 client credentials with a client ID and secret, bearer token valid for about one hour.
CloudCockpit API: Create an Order: order fields including quantity, term duration, billing frequency, auto-renew, and PO number.
CloudCockpit API: Update a customer internal identifier: internal identifier of up to 255 characters on the customer relationship.
CloudCockpit API: Subscriptions: internal id, PO number, and end-dates for coterminosity endpoints.
CloudCockpit API: List all audit logs: status, origin (User, API, System), and correlation ID per operation.