A fitness club is a recurring-revenue business wearing a retail business's clothes, and Dynamics 365 Business Central out of the box is built for neither. BC gives you customers, items, sales invoices and a general ledger — but it has no concept of a membership that renews monthly, freezes for six weeks while a member is injured, and resumes with a pro-rated charge. It has no class calendar, no waitlist, no capacity ceiling per studio, and no notion that a personal trainer earns 40% of a PT session but a flat fee per group class. Clubs end up bolting a standalone gym platform onto Business Central and reconciling by CSV: the membership system says one thing about deferred revenue, the G/L says another, and finance spends the first week of every month proving which one is right.

What we build is a native AL extension — installed as a per-tenant extension, or packaged as an AppSource app where you want it in your own tenant — that puts the club's operating model inside Business Central rather than beside it. Membership plans are a setup table driving a recurring billing engine that generates sales invoices or collection lines from a Job Queue Entry, with deferral schedules so an annual membership recognises revenue across twelve periods instead of landing in one. Freezes, cancellations and upgrades are posted transactions with their own no. series and audit trail, not silent field edits. Class scheduling uses a resource and capacity model: studios and trainers are Resource records, each class instance carries its own capacity, booking status and waitlist, and bookings post attendance which feeds both member usage reporting and trainer pay. Commissions are calculated by a dedicated codeunit that reads the posted attendance and PT session ledger and produces purchase invoices or payroll-ready journal lines against each trainer's vendor or resource card — configurable per plan, per class type and per trainer tier.

Technically it is conventional, deliberately. Table extensions and page extensions hang club fields off Customer, Item, Resource and Sales Header rather than duplicating master data; business logic lives in codeunits with event publishers so your future customisations subscribe instead of patching shipped code; and integration runs through API pages exposed on REST API v2.0 / OData v4 under a service-to-service OAuth registration. Door and access events land in an access log table through those API pages — the turnstile asks Business Central whether a member is current, and the answer derives from live membership status, not a nightly export. Retail sales of supplements, apparel and day passes post as ordinary BC sales lines against your existing item, inventory, dimension and posting-group setup, so stock and margin stay in one ledger. Permission sets ship per role (front desk, trainer, club manager, finance), and where you want dashboards or member messaging beyond BC, the same API surface is consumable from Power Apps, Power Automate and Dataverse. We build against current Business Central release waves, for SaaS or on-premises depending on where your BC actually lives.

This is build-to-order, and that is the honest framing: there is no download button and no instant install. We start with a scoping call, map your plan structures, class types, commission rules and access hardware, and write a fixed scope document. From confirmed scope, typical delivery is one working week — build in a sandbox, UAT on your staging environment with a copy of your data, then a scheduled install into production with a documented rollback. You receive the AL source for your version, a git repository handover, technical and end-user documentation, a training session for front-desk and finance staff, and a post-go-live support window for defects and configuration adjustments. Because you hold the source, the extension stays yours — extend it in-house later, or bring us back for the next wave.