Data Quality Rules Every Finance Team Should Enforce

Finance teams spend a surprising share of month-end fixing problems that were created weeks earlier: a supplier set up twice, an expense coded to the wrong cost centre, an invoice posted in the wrong period. Each error is small. Together they turn a five-day close into a ten-day one and make management reports something people argue about rather than act on.

More checking at month-end will not fix this. A short set of data quality rules, enforced at the point of entry and ideally by the system itself, will.

Why rules beat reviews

Reviews catch errors after they happen. Rules stop them from happening. A finance manager reviewing a trial balance can spot that a figure looks wrong, but tracing it back to the original entry takes time, and by then the supplier may already have been paid or the report already sent.

Rules also scale. A reviewer can check perhaps a few hundred entries properly. A validation rule in the ERP (enterprise resource planning) system checks every entry, every day, without getting tired. The most effective finance teams use people for judgement and systems for consistency.

The rules, grouped by where errors start

Master data rules

• No supplier or customer without a tax number and legal name. Both should match official registration documents. This matters more as e-invoicing systems such as Jordan’s JoFotara and the platform of Saudi Arabia’s Zakat, Tax and Customs Authority (ZATCA) rely on accurate customer and supplier details.
• Duplicate checks on creation. Before a new supplier or customer is saved, the system checks for matching tax numbers, phone numbers and similar names.
• Bank details change only with verification. Any change to a supplier’s bank account requires a second person to approve it and a call-back to a known contact. This single control blocks a common fraud in which someone poses as a supplier and asks for payments to go to a new account.
• A controlled chart of accounts. New accounts and cost centres are created only by finance, with a defined owner and purpose. Users should never be able to invent codes.

Transaction rules

• Mandatory analysis codes. Every expense must carry a cost centre, and where relevant a project, branch or donor code. The system rejects entries without them.
• Unique invoice numbers per supplier. The same supplier invoice number cannot be posted twice.
• Purchase order matching. Supplier invoices above an agreed value must match an approved purchase order and a goods receipt within a defined tolerance.
• Approval limits in the system. Payments and journal entries above set values require a second approver, recorded in the system rather than on paper.
• Descriptions that mean something. Manual journals need a reason and supporting attachment. “Adjustment” on its own is not a description.

Period and reconciliation rules

• Closed periods stay closed. Once a month is closed, postings to it require finance manager approval and are logged.
• Key balances are reconciled monthly. Bank, receivables, payables, inventory, intercompany and sales tax or value added tax (VAT) accounts are reconciled to their sub-ledgers or external statements, with differences explained.
• Suspense accounts are cleared. Suspense and clearing accounts hold entries that have not yet been allocated. Any balance in them at month-end has a named owner and a date for clearing it.

How to enforce each rule

Not every rule can be built into every system, so match the enforcement method to what your ERP supports.

Most mid-market ERPs, including Odoo, SAP Business One and Microsoft Dynamics, support required fields, duplicate warnings, approval workflows and period locking through configuration, though some of these may need an add-on depending on the product and edition. Exception reports can be automated and emailed daily or weekly so that problems are fixed while they are fresh.

An illustrative case: a group with four companies

Take a group in Amman with four operating companies sharing one ERP. Each company’s accountant sets up suppliers independently. Over a few years, the same major supplier appears in the system under several slightly different names, with payments split between them. Intercompany charges are posted with different descriptions in each company, so they never reconcile cleanly, and the group accountant spends days each quarter matching them by hand.

The fix in a case like this starts with a shared supplier master maintained by one person, a duplicate check on tax numbers, a standard intercompany account structure and a monthly automated report that lists intercompany balances that do not agree. None of this is complex. It turns good intentions into rules the system applies every time.

Making the rules stick

Rules work only if people understand why they exist. When introducing them, explain the problem each one solves, and give users a quick way to request exceptions or changes. Review the rules once a year with the finance team. Some will need tightening; others may be creating friction for little benefit.

It also helps to report on the rules themselves. A short monthly summary showing how many entries were blocked, how many exceptions were raised and how many were fixed tells the finance manager whether data quality is improving, and shows which teams need extra support or clearer guidance.

Data quality as a daily habit

Finance data quality is built into the system, not inspected in at month-end. A dozen clear rules, enforced through validation, workflow and automated exception reports, make the close faster and reports more trustworthy, and they reduce the risk of costly errors and fraud.

Data quality controls, master data structures and ERP configuration are a core part of our Enterprise Systems service. We design them around how your finance team already works, starting with the three rules in the callout above.