A laundry is not a warehouse. What you take in is the customer's own property, it must come back to that exact customer, and between intake and collection it splits into individual garments that travel separately through wash, dry-clean, press, spotting and repair. Dynamics 365 Business Central handles the money side of this well — customers, prices, invoices, VAT, receivables — but it has no concept of a garment that belongs to someone else. Sales orders assume you sell items you own. Item tracking assumes serial numbers on goods you stock. There is no page that tells a counter clerk which of a customer's eleven pieces are still in spotting, and no field anywhere that says "ready for Thursday's van route". Most laundries end up running the actual operation on a whiteboard, a spreadsheet or a standalone POS, then rekeying totals into Business Central at month end — which is exactly where the revenue leaks and the disputed tickets come from.

We build a Business Central AL extension that adds the missing operational layer inside the same company database your accountant already uses. A new Laundry Order document captures the customer, promised-ready date and service branch, and explodes into Laundry Garment lines — one record per physical piece, each with its own tag number, garment type, colour, fabric, defect and stain notes, and photographs captured at intake. Tag numbers come from a Business Central number series so they are gapless and auditable, and print to thermal or heat-seal labels as barcodes or QR codes through standard report objects. Each garment carries its own status enum and moves through configurable process stages — Received, Sorted, Cleaning, Pressing, Quality Check, Packed, Out for Delivery, Collected — with every transition written to an append-only Laundry Garment Movement ledger holding user ID, station code, workstation and timestamp. Scanning a tag on a phone or a rugged handheld posts the movement through an API page on the REST API v2.0 surface, so a shop-floor scanning station never needs a full Business Central client.

Pricing is driven by a Laundry Service Price table keyed on garment type, service type, customer price group and optional express tier, so a two-piece suit dry-cleaned on same-day service prices differently from a shirt on standard wash-and-press without anyone typing a figure. Codeunits resolve the price at intake and again at release, so an upgrade to express or an added repair line reprices cleanly and lands on the sales invoice with the correct G/L and VAT posting groups. Corporate accounts — hotels, clinics, airlines, uniform contracts — invoice on a period consolidation rather than per ticket, using standard Business Central customer posting setup rather than a parallel ledger. Pickup and delivery are modelled as a Laundry Route header with stops sequenced per driver and vehicle, and a job queue entry generates the next day's routes on a schedule you configure. Customer notifications — ready for collection, out for delivery, overdue uncollected — fire from event subscribers on status changes and go out over your SMS gateway, WhatsApp Business API or SMTP, with each attempt logged so a "nobody told me" dispute is answerable from the record.

Everything ships with permission sets separating counter staff, plant supervisor, driver and manager, so a driver's app token cannot reprice a ticket. The extension is written for current Business Central release waves on both SaaS online and on-premises, using the extension model only — table and page extensions, codeunits, event subscribers, no base-object modification — so release waves do not break it. Published API pages also make the data reachable from Power Platform and Dataverse for a driver app in Power Apps, a plant-throughput dashboard in Power BI, or an escalation flow in Power Automate.

This is build-to-order. Nothing is downloaded and switched on — we build it against your actual process, because no two plants tag, sort or route the same way. It starts with a scoping call where we walk your intake counter, your plant stages and your delivery model, then we write a scope document naming your stages, your tag format, your price matrix and your notification templates. From a confirmed scope, typical delivery is two to four weeks. You get the AL source code for your Business Central version, deployment to a sandbox for user acceptance testing before anything touches production, a documented go-live with a rollback plan, and a support window afterwards. If your requirement is smaller than what is described here, we scope it smaller and quote it accordingly — the scoping call exists precisely so you are not paying for stages you do not run.