How do we improve data accuracy across different departments?

Why do departments report different numbers?

Different totals do not always mean that someone made a mistake. Sales may count orders, finance may count posted invoices and operations may count fulfilled deliveries. Each can be valid for its own purpose. Problems arise when those measures share the same label or are compared without explaining the difference. Start by identifying whether the disagreement concerns meaning, timing or the underlying records.

Ask colleagues to reproduce one disputed number using the same period and population. Record the filters, date fields and exclusions. A comparison of these steps can reveal differences more quickly than a debate about whose spreadsheet is correct. Keep the discussion focused on the business decision rather than departmental blame. Once the reason is understood, decide whether the measures should converge or remain distinct with clearer names. Data accuracy includes fitness for the intended purpose, so an apparently precise number can still be unsuitable if readers misunderstand what it represents.

Who should own business data?

Assign ownership to people who understand the business meaning and can influence the source process. IT can maintain applications and connections, but it cannot independently decide which customer record is authoritative or what counts as an active account. A finance owner may approve account mappings, while sales operations owns customer classifications and operations owns delivery status definitions.

Separate accountability from daily maintenance. An owner approves the standard and resolves escalated disagreements; a steward may review exceptions and coordinate corrections. Write down both roles and appoint a backup. Avoid creating a committee that discusses problems without anyone having authority to decide. Ownership should include a practical responsibility to explain the data, approve changes and respond when reporting checks fail. Start with the most important entities and measures. A short, maintained ownership register is more useful than a comprehensive catalogue that nobody uses after the project ends.

How do we agree which source is authoritative?

Choose the system of record for each type of information, then identify legitimate secondary uses. One application need not own every field. A CRM might own prospect status while the finance system owns the billing account and posted balance.

The table is an example, not a prescription. Resolve actual ownership with the relevant teams and document how updates flow between systems. Where two systems can change the same field, define how conflicts are detected and resolved before enabling automatic synchronisation.

What belongs in a shared definition of a measure?

Include the purpose, formula, source fields, reporting date and inclusion rules. Explain whether the measure covers orders, invoices or recognised revenue; whether taxes and credits are included; and how currencies are handled. Record how late adjustments affect previously reported periods. Add an owner and an approval date so that readers know who can resolve questions.

Use examples that expose ambiguity. For an illustrative customer-retention measure, ask what happens when a customer buys through a new account, pauses ordering or changes legal entity. The answer should be reflected in the definition and its implementation. Keep related measures distinct where necessary. A commercial pipeline measure and an accounting revenue measure may both be useful without being interchangeable. A shared reporting model can implement the definitions consistently, while the business remains responsible for agreeing them and checking that they continue to fit the decisions being made.

How do customer, product and department identifiers cause errors?

Names are poor substitutes for controlled identifiers. The same customer may appear under a trading name, legal name and abbreviated account name. Products may have legacy codes, supplier codes and internal descriptions. Departments can change names or merge. Joining records on labels alone can create duplicates, omissions or incorrect matches.

Build an approved mapping where systems use different identifiers. Record the source code, target code, effective dates and owner. Route unmatched values to an exception queue instead of silently discarding them or assigning a default that conceals the issue. Test what happens when an account is merged or a product category changes. Historical reporting may need to preserve the classification valid at the time, while a current operational view may intentionally use today's structure. Make that choice explicit. NetMonkeys' system integration services can help assess how identifiers and changes should move between applications.

Which checks should happen when information is entered?

Prevent avoidable errors close to the source. Use required fields, approved lists, sensible formats and duplicate checks where they fit the process. A customer record should not depend on colleagues remembering a reporting convention buried in a spreadsheet. Explain why important fields matter so that controls feel connected to the work rather than arbitrary administration.

Do not make every possible field compulsory. Excessive requirements can encourage placeholder values, invented dates or people recording information elsewhere. Review whether each field is necessary at that stage and who can supply it accurately. Give users a clear route when the approved options do not fit a legitimate case. Monitor the use of unknown or other categories and review patterns with the owner. Source validation works best when it supports an understandable business process, with exceptions handled deliberately rather than forcing users to choose inaccurate values merely to continue.

How should we test data moving between systems?

Define checks at the boundaries of each integration. Confirm expected date coverage, record counts, required fields, duplicate keys and control totals. Preserve enough information to trace an output record back to its source. Where a process updates or deletes records, test those changes as well as new entries. A pipeline that handles new transactions correctly may still leave old records wrong.

Distinguish a technical success from a business success. A scheduled job can finish while loading an incomplete period or an empty result. Set thresholds appropriate to the data and avoid alerting on every harmless variation. Investigate unexpected changes before publishing an important report. Document whether checks block publication, mark data as provisional or create a task for later review. The choice should reflect the consequence of using incomplete information. Integration controls are most valuable when someone is responsible for acting on their results, with a known escalation route when the cause sits in another department.

How can a dashboard make data quality visible?

Use a small set of indicators that lead to action. Show unmatched customer codes, missing classifications, stale feeds or unreconciled balances with an owner and age. Avoid a large quality score whose calculation readers cannot understand. A green percentage can conceal a small number of commercially important errors.

Separate the quality view from the management outcome where necessary, but provide enough context for readers to recognise material limitations. If a sales total excludes unmapped records, display that fact and the size of the exclusion. NetMonkeys' Power BI services can help present operational measures and quality exceptions together. The dashboard should not become a place to permanently repair source data through hidden calculations. Temporary reporting corrections may be necessary, but they need approval, visibility and a plan for resolving the underlying cause. Otherwise, the reporting layer can become another system containing a different version of the business.

What should a practical exception process look like?

Give each exception a category, owner, due date and evidence. Prioritise the impact on decisions rather than treating every blank field as equally important. A missing optional contact field may be low priority; an incorrect account mapping affecting a management report may require immediate review.

Track how long exceptions remain unresolved and which causes repeat. Close the loop with the people entering or maintaining the data. Fixing the same issue in a report every month is evidence that the process needs attention, not evidence that the exception team is working efficiently.

How do we reconcile cross-department reports?

Choose independent controls appropriate to the measure. Financial totals can be checked against an approved ledger report; operational counts can be compared with source records covering the same population and date basis. Reconcile at a level that helps locate problems. A company total may match while regional allocations remain wrong.

Retain a short explanation of material differences and who approved them. Avoid balancing entries added solely to make a dashboard agree. If two reports answer different questions, document the bridge rather than forcing equality. For example, a movement from orders to posted sales might include cancellations, incomplete deliveries and timing differences. Use a representative period with exceptions when testing. Reconciliation should become a repeatable operating control, with clear responsibility and frequency. It is not something performed once at implementation and then assumed to remain valid after system changes, new products or organisational restructuring.

How should we handle historical changes and restatements?

Decide which history needs to remain reproducible. A report may need to show a transaction under the department structure valid when it occurred, or restate history under the current structure for comparison. Both approaches can be useful, but they answer different questions. Label them and preserve the rules used to create each view.

Record effective dates for important mappings and classifications. When correcting an error, assess which existing reports and decisions may be affected. Do not quietly overwrite an approved period if the organisation expects a stable published record. Establish a proportionate restatement process, including approval and communication. Keep personal information only as required by the business's retention and access policies. Historical accuracy is not a reason to create unrestricted copies of sensitive records. The reporting design should preserve the evidence needed to explain a number while respecting the organisation's rules for handling the underlying information.

Can AI solve data accuracy problems automatically?

AI may help identify unusual records, suggest classifications or summarise exception patterns. Treat suggestions as proposals that need appropriate validation. A model can infer a plausible customer match that is wrong, particularly where names are similar or records are incomplete. Define which changes require human approval and keep the original evidence available.

Start with deterministic checks where the business rule is clear. A missing required code or duplicate identifier does not need a generative explanation. Use AI where the ambiguity and potential value justify the additional controls. NetMonkeys' AI consultancy can help assess suitable use cases alongside integration and reporting work. Avoid giving an assistant broad write access merely because it produces convincing suggestions. Accuracy improves when the source process, rules and ownership are clear; AI can assist parts of that work but does not transfer accountability away from the people responsible for the records.

How can we measure progress without creating more bureaucracy?

Select a few measures linked to the original problem: time spent reconciling reports, number of unmatched important records, age of unresolved exceptions and frequency of repeated causes. Establish a baseline before changing the process. Review whether the indicators reflect real improvements rather than simply encouraging colleagues to close tickets or fill fields with placeholders.

Use an illustrative target to organise a pilot, such as resolving all material unmapped accounts before a reporting deadline. The actual threshold should be agreed by the owner based on consequences and available capacity. Measure adoption as well: are departments using the approved definitions, or maintaining parallel versions? Keep governance lightweight enough to operate during normal work. A monthly review of a concise exception list can be more effective than an elaborate governance framework with no connection to current reporting decisions. Expand the controls when the evidence shows where additional effort would matter.

How would a disagreement about regional sales be resolved?

Take an illustrative business where sales reports a different regional total from finance. Both teams agree the overall company total, so they initially suspect a reporting defect. Tracing the records shows that sales assigns customers to the current account manager's region, while finance uses the billing account's original region. A customer transferred between teams during the quarter, and the reports treat its earlier transactions differently.

The business owner decides that performance management needs a historical view based on the region responsible at the time of the sale, while current account planning needs today's ownership. The team keeps both views and names them clearly. It creates an approved effective-dated mapping and tests transactions either side of the transfer date. Finance confirms that the regional allocations sum to the company total, while sales checks the account ownership history.

The resolution is not to declare one department wrong or force both reports into a single unqualified region field. It is to agree the questions each view answers, control the mapping and make the distinction visible. A small set of regression examples is retained for future changes. When another customer transfers, the owner can apply the documented rule rather than reopening the same argument. This is an illustrative process example, without any claimed client result.

What should happen when the business changes structure?

Include reporting impact in the change process for reorganisations, new legal entities and product changes. Ask which identifiers, mappings, access groups and measures are affected. Decide the effective date and whether historical reporting should be preserved or restated. Test a before-and-after example with the owners of the affected reports.

Communicate the approved treatment to readers and update definitions where necessary. A department merger can make a trend appear to improve simply because the population changed. Keep that context visible in management information. Review integration checks as well: a valid new code may otherwise be rejected as an error, while an obsolete code may remain accepted indefinitely. Treating organisational change as a data change helps preserve accuracy after implementation, when the original project team may no longer be closely involved in day-to-day reporting.

How can NetMonkeys help improve trust in our data?

Bring an example of a disputed figure and the reports behind it. Identify the departments involved, the source systems and the decision affected. A useful starting exercise is to trace that one number from entry through integration to presentation, noting where definitions, ownership or controls become unclear.

NetMonkeys' Power BI consultancy can help assess reporting models and quality visibility, while integration work can address inconsistent movement between systems. Where ERP processes are central to the problem, Business Central services provide another relevant route. Ask for clear ownership, prioritised corrections and acceptance tests in any proposal. The practical outcome should be a reporting process that departments can explain and maintain together, with fewer unresolved discrepancies and a reliable way to deal with the ones that still occur.

For the reporting model, Microsoft’s Power BI star schema guidance explains the distinction between descriptive entities and business events. That technical structure supports consistent analysis, while departmental owners remain responsible for the underlying definitions and records.