An ISP or telecom operator runs two businesses at once: a recurring-revenue business and a service-delivery business. Dynamics 365 Business Central handles the general ledger, customers, purchases and VAT very well, but it has no concept of a rate plan, a rated call detail record, a provisioning order, or a service outage. Standard Business Central subscription billing covers flat recurring lines on a contract; it does not tier a customer's 412 GB of data usage across a bundled allowance, apply a fair-use throttle credit, prorate a mid-cycle plan upgrade, or hold an invoice until a mediation batch has finished loading. So operators end up rating usage in a spreadsheet or a separate OSS/BSS product, then re-keying invoice totals into Business Central — which means revenue leakage nobody can trace, a monthly close that waits on a manual file, and dealer commissions calculated outside the system that pays them.

We build a per-tenant AL extension (or an AppSource-targeted app, if you prefer that packaging) that puts the whole cycle inside Business Central. New tables carry Rate Plan, Plan Component, Subscriber Service, Usage Record and Rating Result; table extensions hang subscriber, MSISDN/circuit identifier and service-address fields off Customer and Sales Line; page extensions surface a subscriber FactBox and a service ledger directly on the Customer Card so an accounts clerk never leaves the role centre. Rating runs in codeunits over batched usage records — tiered, stepped, allowance-and-overage, peak/off-peak or flat, whichever your tariffs need — and writes an auditable rating result per record before any invoice line exists, so a disputed bill can be walked back to the exact CDR. A Job Queue Entry runs mediation import and the rating pass on your schedule; invoice generation posts through standard Sales Invoice codeunits so VAT, dimensions, currency and the customer ledger all behave exactly as Business Central intends, and nothing bypasses the posting routines.

The operations side is wired to the same records rather than bolted alongside them. Provisioning workflows move a Subscriber Service through requested, configured, activated and suspended states, with event subscribers (OnAfterPostSalesDoc, order-release and status-change publishers) firing the activation or suspension when the commercial event actually happens — an unpaid account suspends, a paid reconnection reactivates, without a human remembering. Trouble tickets carry priority, category, SLA clock and resolution, linked to the affected service and, where the fault is chargeable, to a billable line. Dealer and collection channels get their own agent records, commission rules and settlement statements, so the people who sold and the people who collected are paid from the same ledger the revenue was recognised in. Everything we build is exposed through custom API pages on the REST API v2.0 / OData v4 surface, so your provisioning platform, softswitch, RADIUS/AAA server, mediation system or self-care portal integrates against a documented, versioned endpoint instead of a nightly CSV. Where you want low-code on top, the same API pages feed Power Apps and Power Automate through Dataverse virtual tables.

Security is designed in, not appended: dedicated permission sets separate the rating operator (can run a rating batch, cannot change a tariff), the billing supervisor (can approve and post), the field/NOC user (tickets and provisioning only) and the setup administrator. Telemetry is emitted so a failed mediation batch or a stalled job queue entry shows up in your Application Insights workspace rather than as a silent gap in a bill run. The extension targets current Business Central release waves and runs on both SaaS online and on-premises deployments; we build against your exact platform and application version, and we test the upgrade path so a Microsoft release wave does not surprise you.

This is build-to-order, and we say so plainly: there is nothing to download today. You request a quotation, we run a scoping call, and we write a specification covering your tariff catalogue, usage record formats, provisioning endpoints, ticket categories and dealer commission rules. Once that scope is confirmed, typical delivery is two to four weeks for a first production-ready version — longer only if you need integrations to systems we have to negotiate access to. You get the AL source code for your version, deployment into your sandbox first, UAT against your own tariffs and your own usage files, then a scheduled production install with a rollback plan. After go-live there is a support window for defect fixes and questions, and the git repository is handed over so you are never locked to us.