Skip to content
Sentinel 1.5 | Preview

Track branch-level registration IDs on invoices in a single legal entity

2026 Release Wave 1 · E-Invoicing

Microsoft source
Score 73/100 · HighImpact HighSwiss relevance LowReleased

Dx365 Analysis

Our interpretation — not a Microsoft statement

What is changing?

Dynamics 365 Finance is gaining a transaction-level establishment concept for organizations that operate several registered branches inside one legal entity. The establishment will be represented through operating units and a dedicated organization hierarchy. Transactions can carry an establishment selected manually or derived from business context, while vendor documents can additionally identify the supplier's originating address. Registration controls can block posting when required identifiers are missing or invalid, and the identifiers used at posting can subsequently be inspected in invoice journals.

Current state today

Standard Finance primarily treats the legal entity and its party/address records as the source of registration information. Sites, warehouses, financial dimensions and operating units can represent operational branches, but they do not provide one consistent establishment-registration mechanism across sales, procurement, projects, journals and intercompany invoicing. Where branch identifiers are required, implementations commonly use document-specific custom fields, financial dimensions, address-dependent registrations, Electronic Reporting logic or manual invoice text. These approaches can produce inconsistent defaults and weak evidence of exactly which registration data was used when a document was posted.

Future state after release

A legal entity will be able to maintain an establishment structure based on operating units, with registration identifiers held against the relevant organization and address data. Supported source documents will contain an establishment reference, and defaulting can be designed around context such as site or financial dimension. Posting controls can check registration requirements, and posted invoices will retain the establishment and identifier information used at that point in time. Vendor processing will also be able to record the relevant ship-from address for registration purposes.

Why it matters

This closes a material standard-product gap for businesses whose branches require separate fiscal, commercial or e-invoicing identifiers without being separate Dynamics 365 legal entities. It can replace document-specific customizations, make registration selection more consistent and provide stronger posting evidence. However, incorrect hierarchy design or defaulting rules could assign the wrong registration to a large number of invoices, so this is not merely a master-data enhancement.

Who is affected?

Dynamics 365 Finance solution architectsAccounts receivable consultants and usersAccounts payable consultants and usersTax and e-invoicing specialistsProject accounting consultantsSales and procurement process ownersOrganization administration and Global address book administratorsMaster-data teamsElectronic Reporting and integration developersInternal control and audit teams

Consultant impact — High

For an affected customer, adoption requires establishment and hierarchy design, registration master-data preparation, defaulting decisions, validation-rule configuration and end-to-end testing across several transaction types. Existing invoice customizations, Electronic Reporting formats, e-invoicing mappings, intercompany flows and integrations may rely on legal-entity, site, address or dimension data and therefore need review. Users must also understand when defaults are acceptable and when an establishment or vendor ship-from address must be changed. Customers without branch-level registration requirements should have limited implementation effort beyond assessing whether activation changes existing forms or posting behaviour.

Likely required work

  • Confirm whether any legal entity contains branches or establishments with separate registration identifiers.
  • Identify the jurisdictions and document types that legally require branch-level identifiers; do not configure controls solely from organizational preferences.
  • Map current sites, operating units, addresses and financial dimensions to the proposed establishment structure.
  • Define ownership and maintenance procedures for establishment registration data in the Global address book.
  • Design deterministic defaulting rules and document the exceptions requiring manual selection.
  • Review registration validation requirements by transaction role and address usage before enabling posting controls.
  • Test free text, sales, purchase, vendor, project, intercompany and general journal scenarios that are used by the customer.
  • Verify corrections, credit notes, copied documents, recurring processes and historical-document inquiry behaviour.
  • Review Electronic Reporting formats, e-invoicing configurations, tax integrations, invoice imports and outbound interfaces for the new data.
  • Regression-test printed invoices, electronic invoice payloads, tax reporting and intercompany reconciliation.

Swiss relevance — Low

Swiss VAT identification is generally associated with the registered taxable person rather than each operational branch, so this is not a broad Swiss localization requirement. It may still matter to Swiss-headquartered groups that keep foreign branches inside one Dynamics 365 legal entity, process invoices subject to another country's establishment rules, or need branch identifiers in cross-border e-invoicing. Applicability should therefore be established country by country rather than assumed for domestic Swiss invoicing.

What should customers do now?

  • Add the feature to the 2026 release assessment for customers with multi-branch legal entities or international e-invoicing obligations.
  • Create a branch-registration inventory covering legal entity, operating unit, site, address, jurisdiction, identifier type and effective dates.
  • Prototype one customer invoice and one vendor invoice flow before redesigning all document processes.
  • Compare the standard capability with existing branch-ID customizations and prepare a retirement or coexistence plan.
  • Validate expected electronic invoice output with the applicable tax authority, service provider or local compliance adviser.
  • Treat activation as optional until business applicability, feature management behaviour and regression scope have been confirmed in a sandbox.
  • Resolve the apparent release-plan status inconsistency before scheduling production deployment.

Release Radar score — 73/100 (High priority)

The feature has strong Finance and compliance relevance for the affected international and multi-establishment customers, spans several high-volume transaction processes and may eliminate significant customization. Its overall customer reach is narrower because many legal entities use only one registration identity, and direct Swiss relevance is limited. The score also reflects meaningful configuration and regression effort, while treating June 5, 2026 as the operative availability date because the supplied status information is inconsistent.

Assumptions, not Microsoft-confirmed facts

  • The supplied metadata says both Generally Available and June 5, 2026. This analysis assumes June 5, 2026 is the planned production availability date and that the status label may be premature or generated inconsistently.
  • The exact feature-management switch, prerequisites, supported countries and deployment sequencing are not clear from the supplied information.
  • It is not clear how establishment defaults are prioritized when site, financial dimension and manual values conflict.
  • The behaviour for credit notes, invoice corrections, copied transactions, recurring journals and document reversals is not specified.
  • The extent to which stored identifiers are exposed to Electronic Reporting, data entities, APIs and e-invoicing transformations requires product validation.
  • The treatment of identifier validity periods and changes to registration master data after posting is not sufficiently detailed to infer exact behaviour.

Microsoft information

Quoted from the release plan

Business value

Many jurisdictions require that invoices and financial documents include not only the legal entity’s primary registration number but also identifiers for specific branches or establishments involved in the transaction. This feature introduces a standardized way to manage and apply establishment-level registration data across all relevant financial processes in Dynamics 365 Finance. By enabling organizations to define and associate multiple establishments within a single legal entity, this functionality ensures that the correct registration IDs are automatically applied to customer and vendor invoices, purchase and sales orders, and project transactions. This capability reduces manual data entry, improves audit readiness, and supports compliance with evolving global e-invoicing and tax reporting mandates.

Feature details

This feature introduces the concept of an Establishment within a legal entity, allowing organizations to manage and apply establishment-specific registration identifiers such as branch IDs and local registration numbers across invoices. The feature provides the following key capabilities: - Establishment modeling: Establishments of the legal entity are modeled using Operating units, with a new organization hierarchy purpose called Enterprise establishment structure. Each establishment can be assigned unique registration identifiers through the Global address book. A new Establishment field is added to key transaction documents, including: - Free text invoices - Sales orders - Purchase orders - Vendor invoices - Pending vendor invoices - Project invoice proposals - Intercompany customer invoices - General journals The establishment can default based on context, such as site or financial dimension, or be selected manually. After a transaction is posted, the establishment reference is stored immutably for audit and compliance purposes. - Vendor ship-from address tracking: A new Ship-from address field is introduced on vendor-facing documents, allowing users to specify the originating establishment of goods or services. The associated registration identifiers are captured and stored on the invoice. - Registration ID validation rules: Administrators can configure validation rules to enforce the presence and format of registration IDs based on address purpose and role such as invoice or delivery. The system validates these rules during transaction posting, ensuring data completeness and consistency. - Post‑posting review of registration IDs: After an invoice is posted, the registration IDs that were applied and stored can be reviewed directly on: - Customer invoice journals - Vendor invoice journals - Project invoice journals - Use cases: - Organizations with multiple branches or operational sites under a single legal entity. - Businesses operating in jurisdictions that require branch-level registration data on invoices. - Enterprises preparing for or complying with e-invoicing mandates or tax authority reporting requirements.

Change history

Differences detected between scans

  • status03 Oct 2026

    The release status moved from Generally Available to Released.

    Previous
    Generally Available
    Current
    Released
  • added12 Aug 2026

    Microsoft added this feature to the Dynamics 365 Finance release plan.

    Previous
    —
    Current
    Generally Available
Back to Release Radar³