Dynamics 365 Commerce Modern Receipt Designer: Safe Migration to Browser-Based A4 and Thermal POS Printing

What Microsoft shipped​

The modern receipt designer is a React-based design experience for Commerce receipt formats, available directly from Commerce headquarters. It appears in the Commerce 10.0.49 release, which has build number 10.0.2790. That release's schedule is a preview in July 2026, general availability for self-update in September 2026, and general availability for auto-update in October 2026. The Microsoft roadmap entry lists the feature as "Launched", with preview in July and general availability in October 2026. Self-update and auto-update customers get the release at different times, so don't treat October as a single date for everyone. Roadmap dates can also change.

In headquarters, the designer is under Retail and Commerce > Channel setup > POS setup > POS > Receipt formats > Designer. The older approach was different. Selecting Designer started installation of the Commerce designer host, and users then had to enter their Commerce credentials. The new designer runs in the browser. Microsoft lists these features:

• predefined templates
• drag-and-drop placement of elements
• inline line adding
• a live preview pane
• end-to-end saving of formats
• custom fields

Why A4 matters for POS​

Thermal receipts suit a typical retail counter. Trade counters and B2B sellers often have to hand over a full-page invoice or order receipt. Microsoft says Hardware Station now supports both A4 and thermal paths. The OPOS, network printer and Windows print routes each convert the structured receipt into output for that platform.

Underneath is a new structured receipt schema. It has Header, Footer and Lines sections and is stored in headquarters. It is synchronized to the channel database and used by the following components:

• Commerce Scale Unit, through ReceiptService V2
• Store Commerce
• Hardware Station

Because the receipt document isn't tied to one device, Store Commerce and Hardware Station can use the same document for preview and printing.

The documentation doesn't publish a printer compatibility list. It doesn't promise that an existing printer setup will work untouched. Plan to test each printer model and driver you actually run.

Prerequisites before you enable it​

Microsoft's guidance, in order:

1. Update Commerce headquarters and Commerce Scale Unit to versions that include the designer and the structured receipt endpoint.
2. Update Store Commerce to a version that supports structured receipt preview and printing.
3. Keep your existing receipt profiles, printers and hardware profiles configured for the registers that print receipts.
4. Turn on the modern receipt designer feature in Feature management.

Microsoft warns about step 4. Store Commerce can use the structured receipt path only when the feature is enabled and the Scale Unit supports structured receipts. Microsoft's documentation says that if the endpoint isn't available, receipt preview or printing can fail. In practice, enabling the flag before the Scale Unit or Retail Server is updated is the one way to break receipts at the register.

Migration doesn't happen on its own​

Turning on the feature doesn't migrate existing formats. After enabling it, an administrator must open each existing format in the modern designer and select Save. That creates the structured layout data. A format that hasn't been saved this way isn't available through the structured path. If you have dozens of formats across channels, plan this as a project.

The changes are also one-way. Anything saved in the modern designer isn't written back to the legacy format. If the feature is later disabled, changes made only in the modern designer won't appear in the legacy designer. They come back if you re-enable it. Rolling back is therefore possible, but it can leave you with two diverging versions of the same receipt. Keep a record of which format you're editing in which designer.

The roadmap also says that:

• existing formats, Hardware Station extensions and print integrations keep working when the flag is off
• demo data now includes sample formats
• Microsoft documents how to migrate Hardware Station extension code that depends on legacy fields

I could only verify the Microsoft Learn text that I could read. That text confirms the opt-in behavior but doesn't spell out the extension-migration details. If you have custom Hardware Station extensions, treat them as a testing risk.

Using the designer​

The documented workflow:

1. In headquarters, open Receipt formats and create a format or select an existing one.
2. Select Designer.
3. If the format has no modern design yet, pick a template from the gallery or start blank.
4. Select Edit format to open the full canvas.
5. Find fields in the palette, where standard and custom fields are grouped separately, and drag them onto the canvas.
6. Select a field to change properties such as position, length, alignment, font weight, prefix or text.
7. Resolve any validation errors.
8. Select Save.

After you save, the Receipt formats page shows an embedded preview. You can reuse a finished design with Save as Template. The template gallery appears only for formats without a modern design. It can't apply a saved template to a format that already has one.

The designer also validates lines as you work. It can flag fields that conflict with the line type, fields that overlap on a line, and lines whose type needs to be inferred or corrected after you move fields. The checks catch layout mistakes. They don't show you how a particular printer will render the receipt.

In version 10.0.49, custom fields show up in the palette under their configured captions. If a translation exists for the current legal entity and language, that caption is shown. Otherwise the field name is used. Standard field labels and sample preview data are localized too.

The roadmap description also mentions a strikethrough font for original pricing, an automatic duplicate indicator with the reprint date and time, and editing of EFT/card information in the main receipt flow. I couldn't confirm those in the Learn pages I could read. Check them in your own environment before promising them to a customer.

What the structured path covers​

According to Microsoft Learn, the structured path covers these flows:

• post-sale receipt printing, and gift receipt printing or emailing
• journal receipt preview, print, print all, quick email, gift receipts and document-based preview
• Customer Transactions preview and print
• cash-management receipts: bank drop, safe drop, tender removal, starting amount, tender declaration, open drawer, void transaction, suspend transaction and gift card inquiry

Print behavior still follows the receipt's setting: Always print, Prompt user or Do not print. Microsoft says receipts and other documents print from Store Commerce and Store Commerce for web only when form layouts and receipt profiles are set up. A receipt profile is assigned to a printer through the hardware profile, and the profile can contain several layouts. Microsoft's example is a two-printer setup. One printer handles standard 40-column thermal receipts. The other prints full-page documents such as customer order receipts and invoices. That's a sensible pattern for A4, but the documentation doesn't present it as a mandatory A4 setup.

Suggested rollout sequence​

This sequence is my synthesis of Microsoft's prerequisites, not an official vendor checklist.

1. Update headquarters, the Scale Unit or Retail Server, and Store Commerce.
2. Confirm printers, hardware profiles and receipt profiles.
3. Enable the feature in a non-production environment first.
4. Open and save every format you need in the modern designer.
5. Check the embedded preview.
6. Run the standard Commerce data distribution job, as the roadmap describes.
7. Print test receipts on each real A4 and thermal device, including the reprint, gift and cash-management receipts.

Related developments and caveats​

A related roadmap item describes a Copilot Cowork skill for authoring receipt formats. Per the Microsoft 365 roadmap, it works on formats already in the modern structured representation. Roadmap entries say that structural checks don't establish visual appearance, barcode scanability, runtime values, or legal and fiscal compliance, and that users should test print before operational use. That fits the broader point. The designer reduces friction, but it doesn't remove the need to test printed output.

Microsoft's own sources are the only ones I could use here, and they describe the benefits in favorable terms. No independent hands-on reports came up in my search, so real-world printer behavior is still unproven. For retailers with many legacy formats, custom Hardware Station extensions or fiscal receipt requirements, the migration work could outweigh the editor's convenience. For B2B counters that have wanted A4 invoices straight from POS, it's a long-awaited option.