Blog
What's new in Business Central 2026 release wave 2 (v29)
Microsoft has rolled out the public preview environments for update 29 (2026 release wave 2). General availability follows in the first week of October, which leaves roughly a month to test. This time the most important change in the release is one you cannot see in any screenshot, so the testing month matters more than usual.
The change you cannot see: a new data model for table extensions
Until now, fields added by a table extension lived in a separate companion table in SQL, joined to the base table at runtime. In update 29, all fields of an AL table are stored in one database table, which makes every database operation that touches extension fields faster. Developers can also define keys that span base table and table extension fields, something the old model simply could not do.
Why it matters: every environment with extensions benefits, and that is every environment we have ever worked on. Slow lists and reports that filter on extension fields should improve without a single line of code changing. But a restructuring this deep is exactly what preview sandboxes exist for: update an existing sandbox that has your extensions and your data to 29.0 preview, rather than testing in a clean one, and run your heaviest processes against it.
Reporting grows up
Update 29 delivers a bundle of reporting features that fit together. Report themes give document reports a consistent look on PDF output, settable globally, per company, per report or per layout. Header and footer layouts can be reused across document reports, and the Word add-in gets new design components, conditional visibility (HideIf) and a shared company-information dataitem so layouts need less plumbing. Finance teams get report packs: define a set of financial reports, run or schedule them, and receive a single PDF. And changes to financial report definitions are now always logged in the change log.
Why it matters: month-end reporting packs are still assembled by hand in most companies we see, and when an auditor asks who changed a row definition, the answer has usually been a shrug. Both of those problems now have a standard answer. If you maintain custom document layouts per customer or per brand, the theme and header/footer reuse alone will shrink that layout zoo.
The Expense Agent turns into a process
The agent story continues, and this wave the Expense Agent gets the most attention: an approval process with AI-based policy validation that flags suspicious or non-compliant lines, mileage rates by date range and vehicle type, travel requisitions with multiple travellers, better duplicate detection that also checks posted documents, and withholding tax calculation inside expense reports. The Payables Agent improves purchase order matching with line amounts and expected receipt dates, and the web client adds a review bar on lists showing documents where an agent is waiting for a human.
Why it matters: expenses are a good place to let an agent work, because the approval stays with a person and the damage radius of a mistake is one reimbursement, not a ledger. The policy validation is the part we would pilot first: it does the tedious checking nobody enjoys, and the interim-approver and duplicate features close the gaps that made earlier previews feel unfinished.
E-documents learn EDI, and finance features go standard
The e-documents framework can now exchange orders and payments using the Peppol BIS 3 EDI standard, extending the same rails that carry e-invoices to document types that used to require EDI middleware. On the finance side, several things that used to mean a localisation app or custom code arrive in standard: withholding tax for vendors and for employee transactions, multiple excise duties per item, accelerated depreciation methods for fixed assets, and vendor-specific number series for self-billing invoices.
Why it matters: each of these replaces something customers currently pay a partner or an ISV for. Before scoping any new work in these areas, check this list first; the cheapest code is the code Microsoft now ships.
Developer notes
The AL platform takes a big step this wave. Interfaces support default method implementations, so an interface can finally evolve without breaking every implementor. Existing Integer fields can be migrated to BigInteger with compiler warnings on expressions that might overflow. Record.IsDirty reports uncommitted changes, transaction isolation becomes controllable for queries and isolated storage, and the compiler warns when a table approaches SQL column limits. Tooling follows suit: ALTool can compile, deploy and run AL tests from CI/CD pipelines with structured JSON results, the AL language server runs standalone for AI agents and other editors, and the MCP server gains tools to define and run custom data queries where no API exists.
Why it matters: default interface implementations and BigInteger migration remove two long-standing reasons to postpone refactoring. The CI/CD test runner is the one to adopt immediately; running the test suite on every pull request stops being a custom scripting exercise.
A month to test, and a small goodbye
To try the preview, create a sandbox on version 29.0 preview in the admin centre, or update an existing sandbox to it. Preview sandboxes are deleted 30 days after general availability, in early November, so treat them as disposable. One more change worth noting: from September 2026 Microsoft stops publishing release plans altogether; upcoming Business Central capabilities appear on the AI at Work roadmap instead, so bookmark accordingly.
Not sure how your customisations will behave on the new table extension data model? Tell us your story and we will run your scenario in a preview sandbox before October does it for you.