Master data management: what bad customer and supplier data costs every month

Master data management in finance means keeping the records behind every transaction correct and unique: customers, suppliers, bank details, VAT IDs, payment terms, items, accounts and cost centres. When this data is wrong, nothing fails loudly. Payments go to the wrong account or twice, open items never balance, discounts are missed, and the DATEV export carries the errors to your tax advisor. The cost is paid every month, in small amounts and hours.

Most companies treat master data as a cleanup project before a system change. That helps once. The lasting fix is to stop bad records at the moment they are created, because every duplicate created today becomes a reconciliation problem at month-end.

---

What counts as master data in finance?

Master data describes the parties and structures a company works with. It changes rarely, and every transaction refers to it. Transaction data, by contrast, records what happened: invoices, payments, bookings, stock movements.

In finance, the master data that matters most is:

• Suppliers (Kreditoren): legal name, address, VAT ID, IBAN with the account holder's name, payment terms, default expense account and cost centre.
• Customers (Debitoren): legal name, billing address, VAT ID, payment terms, dunning contact, and for public or larger customers the order or routing reference they require on invoices.
• Items and services: description, unit, VAT rate, revenue account.
• Structures: chart of accounts, cost centres, projects and entities.

Each supplier and customer usually has its own personal account (Personenkonto) in the ledger and in DATEV. That makes the record more than a contact entry. It is where open items, payments and balances live.

What does bad master data cost every month?

The cost rarely shows up as a single line. It spreads across the month as extra work and small losses.

• Time. Every invoice from a supplier with incomplete data needs a manual step: look up the IBAN, ask for the VAT ID, pick the account by hand. Multiply that by a few hundred invoices a month.
• Duplicate and failed payments. If the same supplier exists twice, an invoice can be paid from both records. A wrong IBAN or account holder name means a returned payment, a late payment and an annoyed supplier.
• Missed early-payment discounts. Payment terms stored incorrectly, or not at all, mean invoices are paid on the default term and the discount (Skonto) is lost.
• Receivables that do not match. A customer recorded twice receives reminders for invoices already paid against the other record. Incoming payments land on the wrong account, which makes payment reconciliation slower for everyone.
• VAT risk. A missing or invalid VAT ID for an EU customer can break the reverse-charge treatment of a cross-border invoice, as explained in reverse charge and EU invoices. A wrong legal name or address on an incoming invoice can put the input VAT deduction at risk, since name and address are mandatory invoice details under § 14 (4) of the German VAT Act (UStG).
• Rejected e-invoices. As structured e-invoices become standard in German B2B, customers increasingly reject invoices that lack their order reference or carry the wrong legal entity.

None of this appears in a budget. It appears as a longer close and a finance team that is always busy.

Why do duplicate suppliers break the DATEV export and the payment run?

Duplicates are the most expensive master data error, because they split one business relationship across two accounts.

Consider one supplier recorded twice, once as "Müller GmbH" and once as "Mueller GmbH", with two personal accounts. Invoices are booked to either record, depending on who captured them. The open items list now shows two partial balances, neither of which matches the supplier's statement. The supplier statement reconciliation turns into detective work.

The payment run inherits the problem. One record has the current IBAN, the other an old one. An invoice arriving twice, once by email and once by post, can be captured against both records and slip past a duplicate check that only looks within one account. The safeguards for that step are described in batch payment runs.

Since 9 October 2025, banks in the EU must also check the payee name against the IBAN before executing a euro credit transfer (Verification of Payee). If your supplier record holds a trading name rather than the exact account holder name, transfers come back as a mismatch. Companies can send bulk payments without the check, but then they give up a fraud safeguard. Clean names in the supplier record are the better answer.

Finally, the DATEV export carries every duplicate to your tax advisor (Steuerberater). Two personal accounts for one supplier mean two sets of open items in their system, questions at month-end and corrections that someone has to book. The requirements for a clean handover are in the DATEV export.

Which fields matter most for German compliance?

Not every field deserves the same attention. For a German company, five carry most of the compliance weight:

1. Legal name and address exactly as registered, because they appear on invoices and must match.
2. VAT ID, checked against the EU system. For German companies, the Federal Central Tax Office (BZSt) confirms foreign VAT IDs on request (§ 18e UStG). Store the date and result of the check with the record.
3. IBAN and account holder name, with every change approved by a second person and confirmed through a known contact, not through the email that announced the change.
4. Payment terms and discount, so the payment run pays at the right time.
5. Tax treatment and default accounts, so bookings and VAT keys are consistent.

The GoBD (German digital bookkeeping rules) add one more requirement. When master data changes, earlier bookings must keep their original meaning (Rz. 111). In practice, changes are either prevented or recorded with a history and validity dates. Overwriting a supplier's bank details without a trace is a control gap and a GoBD problem at the same time.

How do you keep master data clean without a cleanup project?

A one-off cleanup removes today's duplicates. Without changes to how records are created, they return within a year. Four practices keep the data clean:

• One owner per record type. Someone in finance owns supplier records, someone owns customers. Others can request changes but cannot make them alone.
• Checks at entry. A new supplier is compared against existing records by name, VAT ID and IBAN before it is created. Mandatory fields are actually mandatory.
• Approval for sensitive changes. Bank details, legal names and payment terms are changed only with a second approval, and every change is logged.
• One source of truth. If customer data lives in the CRM, the invoicing tool and the accounting system, it will drift. One system should hold the record, and the others should read from it.

Then review once a quarter: inactive records, records without a VAT ID, suppliers with changed bank details and customers with more than one account.

How does Agent F catch bad records on entry?

In Agent F, suppliers, customers, items and accounts live on one data model shared by purchasing, sales, payables, receivables and the ledger. A supplier created during invoice capture is the same record the payment run and the DATEV export use.

When a new record is created, the AI layer compares it against existing ones and flags likely duplicates, such as a similar name, the same VAT ID or the same IBAN, with a confidence score. A person decides whether to merge, link or create. Incomplete records are flagged before the first booking, not at month-end. Changes to bank details trigger an approval and are written to the audit trail with the old and new values, and anomaly detection highlights a changed IBAN shortly before a large payment.

To start, export your supplier list and sort it by VAT ID and IBAN: every value that appears twice is a duplicate to resolve. Then check which suppliers lack the exact account holder name, and agree with your tax advisor how merged accounts should appear in the next DATEV export.

Learn how Agent F works, or see it on your own supplier and customer data at agent-f.ai/demo.