Date Formatting in Business Central Without Losing Your Mind
Most people discover they need dates in yyyymmdd format when they're trying to export data to a legacy system or a bank file. It sounds simple, but the actual mechanics in Business Central are more annoying than the documentation suggests. You can't just change a setting and be done with it. In standard Business Central, dates are stored internally as numbers. When you reference a Date field, you're working with an integer, not a string. That means any conversion to yyyymmdd has to happen explicitly in your code. The FORMAT function is the standard approach, and it looks like this: FORMAT(MyDateField, 0, '<Year4><Month2><Day2>')
This gives you a string like 20240315. The second parameter (0) refers to the decimal places, which is irrelevant for dates but required by the function signature. The third parameter is where the magic happens. The angle brackets force fixed-width formatting, so a single-digit month like March becomes "03" instead of "3". Without those brackets, you'd get 2024315, which breaks most downstream processes. I learned this the hard way. About two years ago, I was working on a project where we needed to feed transaction dates into a payment processing API that accepted only yyyymmdd strings. I wrote the conversion, tested it, and everything looked fine in the test environment. Then we pushed to production and the integration started failing. The issue was that our test data only contained dates with single-digit months in January and February. When the converter ran against real data with two-digit months, the format string behavior changed slightly depending on locale settings. The workaround was wrapping the FORMAT call with an explicit conversion to ensure the output was always exactly 8 characters, regardless of input.
Where People Go Wrong
The most common mistake is assuming FORMAT behaves the same way across all deployment types. On-premises installations respect the server's regional settings in ways that cloud deployments don't. If your business central is hosted on-prem and the server is set to European date format (dd/mm/yyyy), the FORMAT function's internal handling can produce unexpected results when you're combining it with other string operations. I've seen implementations where the month and day digits got swapped because someone assumed the function was culture-invariant when it isn't. Another thing that trips people up is blank dates. If you try to FORMAT a BlankDate, you get an error, not an empty string. The fix is a simple NULL check before the conversion, but it's easy to forget in bulk data processing scripts. For calculated fields on pages, you can create a field directly in the page extension and use the same FORMAT expression. This works for display purposes but won't help if you need the value stored in a database column or sent through an API.
Get the Full Details
API and Integration Considerations
If you're exposing dates through OData or REST APIs, the default behavior is ISO 8601 format (yyyy-mm-dd with hyphens). Converting to yyyymmdd without hyphens requires either a custom endpoint or post-processing on the consumer side. There's no built-in switch to change the serialization format for date fields in web services. For batch processes and data migration, I typically recommend creating a simple codeunit that handles the conversion with error checking. Here's the pattern I use: If ISNULL(MyDate) THEN
Result := ''
ELSE
Result := FORMAT(MyDate, 0, '<Year4><Month2><Day2>');
This avoids the crash on blank dates and produces consistent output. The empty string on NULL is important because many external systems expect a placeholder rather than failing outright.
Limitations Worth Knowing
There's no way to globally change how dates are displayed or formatted in Business Central. Each instance of date-to-string conversion needs to be handled individually. If you have dozens of pages, reports, and codeunits that all need yyyymmdd output, you're looking at a lot of repetitive code. I've seen teams solve this by creating a central utility function that other code calls, but even then, every field that needs conversion has to be updated manually. The other significant limitation is that this approach only produces strings. If you need actual date values in a different format for sorting or comparison, you're out of luck. The FORMAT function always returns text. You'd need to use date arithmetic if you want to manipulate the resulting value further. For complex reporting scenarios where you need dates in multiple formats simultaneously, consider using a single source of truth. Store your dates in standard format and apply the conversion only at the point of output. This reduces duplication and makes maintenance significantly easier than trying to store dates in multiple representations throughout your database.
