Prevent errors at the source

Business Central data quality is decided at the moment of entry, not at month-end. One wrongly filled field on a customer card or a journal line sits in your data from that moment on, and every report you run afterwards inherits it. Exsion 365 therefore combines two things: Exsion Reporting to find the errors that did get through, and Field Validation from 2-Controlware to stop the most common ones at the source. Thomas Werkhoven, director of Exsion 365 and still a controller himself, explains why Exsion started using Field Validation in its own administration this year, and how clean source data keeps live Excel reporting on Business Central reliable.

Why do reporting errors start at data entry?

Poor data in your reporting almost always starts at entry, not in the reporting itself. Thomas sees this from both sides. "I own Exsion, but I also come in at clients as a controller or CFO. And then you see where it goes wrong: someone fills in a field incorrectly, and from that moment the error sits in your data."

The mechanics in Business Central make this worse than it sounds. A posting group or a dimension is copied from the master record (the Customer table, table 18, or the Vendor table) onto the document, and from the document onto the posted ledger entries in G/L Entry (table 17), Cust. Ledger Entry (table 21) or Vendor Ledger Entry (table 25). Once posted, those entries cannot be edited. A wrong VAT business posting group on one customer card does not produce one wrong line; it produces a wrong line on every invoice for that customer until someone notices.

You usually notice when the figures are already out. Then you are fixing errors instead of reading what the figures are telling you. As Thomas puts it: one wrongly filled field, and a controller can spend half a day working out why the numbers do not add up.

What does it cost to find an error at month-end instead of preventing it at posting?

The same error has a very different price depending on where in the chain you catch it. At entry it costs a few seconds, because the user simply corrects the field before the record is saved. After posting it costs a reversal, a correcting entry, a note for the auditor and often a conversation with the colleague who made the entry. At month-end, when the report has already been sent, it costs credibility.

[[TABLE_START]]

Where the error is caught | Who fixes it | What it takes | Effect on the report

At entry, before saving | The person entering the data | Correct one field, a few seconds | None, the record is right from the start

At posting, in the journal | Finance, same day | Check the preview, correct the line | None if caught before posting

After posting, during the month | Controller | Reversal plus correcting entry, audit trail | Report still correct at month-end

At month-end, in the report | Controller, under time pressure | Search across ledger entries, reverse, re-run the report | Close is delayed, figures already shared may change

After the report has gone out | Controller and management | Explain the restatement | Trust in the figures drops

[[TABLE_END]]

That is the core argument for prevention. Exsion has been using Field Validation for a few months, so Thomas is careful with hard figures. "What I notice is that the source data comes in cleaner and that we spend less time on rework."

Exsion can already find errors, preventing them is the next step

Exsion Reporting is good at finding. You pull G/L Entry (table 17) or Cust. Ledger Entry (table 21) into Excel, refresh, and a validation report shows straight away where something is off, for instance an entry on the wrong account or a missing dimension. With 700,000 G/L Entry rows loading in under five seconds, a full-ledger check is a one-click job rather than an afternoon. "Exsion is the detective, it establishes what is going wrong," Thomas explains.

The limit of detection is that it always comes after the fact. You can refine your report as much as you like, but you keep spotting errors after they have already been made. Next month someone types the same field wrongly again. So the real gain is not in better spotting, but in prevention, and that only works if the data is right at the source.

What does Field Validation do in Business Central?

Field Validation from 2-Controlware sets rules on fields in Business Central. If something is forgotten or filled in wrongly, the user cannot proceed until it is right. You decide yourself when a rule applies, so users do not get messages at the wrong moment; a rule that is relevant for an EU customer does not bother someone creating a domestic one.

Thomas gives examples from Exsion's own administration. "For a customer with an EU VAT business posting group, a VAT number has to be entered. An invoicing email address has to be there, so the invoice ends up in the right place. And for contracts we record the right deferral code, together with the end date and the partner dimension."

Those three examples cover the categories that cause most rework: a tax field tied to a posting group, a reference a downstream process depends on, and a set of fields that must be complete together.

Which fields and postings typically go wrong?

Ask any controller who closes books in Business Central and the same handful of fields comes up: optional in the standard setup, mandatory for your reporting.

• Dimensions. A cost center or project dimension left blank on a purchase line means the cost lands in the P&L without an owner. In the dimension report it shows up as a blank column that someone has to allocate by hand.

• Posting groups. A wrong general business or general product posting group sends revenue or cost to the wrong G/L account in the G/L Account table (table 15). The total is right, the split is wrong, and nobody sees it until the margin analysis looks odd.

• VAT fields. An EU customer without a VAT registration number, or a VAT business posting group that does not match the country, leads to a VAT return that needs manual corrections.

• Missing references. A missing invoicing email address, external document number or contract end date does not break the posting, but it breaks the process behind it: the invoice does not arrive, the reconciliation does not match, the deferral runs one month too long.

For each of these, the standard Business Central setup offers some protection (for example mandatory dimension values on an account), but much of it sits at account level rather than at the level of a specific customer, vendor or contract. Field Validation lets you set the rule exactly where the error happens, on the card or the line, under the conditions you define. Microsoft's finance overview on Microsoft Learn describes the standard posting setup that these rules build on.

How do Field Validation and Exsion Reporting work together?

Field Validation and Exsion Reporting reinforce each other. "Exsion establishes what is going wrong, and with Field Validation you make sure it does not happen again," says Thomas. In practice the loop looks like this.

1. Build a validation report in Excel with Exsion Reporting: for example all G/L Entry rows for the period with an empty department dimension, or all customers with an EU posting group and no VAT number. Refresh takes seconds and the query definition is stored in the workbook, so the check is reusable every month.

2. Look at the pattern. Is it one account, one user, one document type? That tells you whether the fix belongs in Business Central's standard setup or in a field rule.

3. Where the error repeats, add a rule in Field Validation on that field, with the condition under which it applies.

4. Keep the Exsion check running. Next month the report should come back empty. If it does not, you have found the next rule to add.

Sometimes you catch an error with Exsion within the Business Central standard. In other cases a validation on a field is exactly what you need. That way you cover the whole chain, from entry to reporting. A related approach for the ledger itself is described in general ledger checks without the hassle.

Why does clean source data make live Excel reporting reliable?

Exsion Reporting reads live Business Central data through the API, with no copy in a warehouse or an Azure database in between. The report always shows what is in Business Central right now, across every company you tick in the query grid. It also means the report is exactly as good as the source; there is no transformation layer where someone quietly patches a blank dimension.

With Field Validation in front of it, that directness becomes an advantage rather than a risk. The 16 live financial functions, the pivot on up to 25 million rows and the Show Details drill-down that opens Business Central on the exact account and date range all rely on the entries carrying the right account, dimension and posting group. Clean entry means the drill-down explains the number instead of exposing a data problem. It also means the checks in automated variance analysis flag real business variances, not entry errors.

Why 2-Controlware?

That it became 2-Controlware felt logical. "The founder is a chartered accountant, like me, and he has worked with Exsion for years himself," Thomas says. They met at a client day of a shared partner and now run webinars together. "Where he has been a fan of Exsion for years, I have become a fan of his Field Validation." No coincidence, because they look at data the same way: better right at the source than fixed afterwards.

The first experiences

Thomas sees a wider shift among Exsion users. "In recent years controllers have increasingly used Exsion not only to report, but also to check their figures." For him, Field Validation is the next step: not just seeing that something is wrong, but preventing it from happening. The cleaner the source, the more of the month a controller spends on what the figures mean.

Want clean data at the source yourself?

Do you work with Business Central and recognise that stream of data entry errors? Clean data at the source and reliable reporting in Excel belong together. Exsion Reporting installs from AppSource in about five minutes, with a 30-day full trial and public pricing. Get in touch with Exsion 365, and we will show you how the combination of validation at entry and live reporting in Excel works in your situation.

Thomas Werkhoven is director of Exsion 365 and still works as a controller.

Frequently asked questions

[[FAQ_START]]

What is Field Validation for Business Central? | Field Validation is a Business Central extension from 2-Controlware that sets rules on fields. If a field is forgotten or filled in wrongly, the user cannot proceed until it is right, and you decide yourself under which conditions each rule applies.

Is Field Validation part of Exsion Reporting? | No. Field Validation is a separate product from 2-Controlware that Exsion 365 uses in its own administration and recommends alongside Exsion Reporting. Exsion finds the errors in your data, Field Validation prevents them at entry.

Which Business Central fields most often cause reporting errors? | Dimensions such as cost center or project, general and VAT posting groups, VAT registration numbers on EU customers, and reference fields such as invoicing email address, external document number and contract end date.

Why not just correct errors after posting? | Posted ledger entries in Business Central cannot be edited, so every correction is a reversal plus a new entry, and the same error tends to come back next month. Preventing it at entry costs seconds; fixing it at month-end costs hours and can delay the close.

How do I find existing data errors in Business Central? | Pull the relevant table, for example G/L Entry (table 17) or Customer (table 18), into Excel with Exsion Reporting and filter on empty dimensions, mismatched posting groups or missing VAT numbers. The check runs in seconds and can be reused every month.

[[FAQ_END]]