Preparing ERP Master Data Before Implementation

A successful import can still create an unusable ERP

A supplier may appear twice because purchasing uses an English abbreviation while finance records an Arabic legal name. A product may be bought in cartons and sold in pieces, with an undocumented conversion between them. An import tool can load every row successfully and preserve both problems. Data readiness means agreeing what records represent, who owns them and how their relationships will be checked before operational teams depend on them.

For an operations lead preparing an ERP implementation, the first deliverable should be a data decision register. It names each domain, the authoritative source, the business owner, the transformation rule and the evidence required for acceptance. A developer can implement a rule; the business must decide whether the rule is correct.

Separate three kinds of information

Configuration describes how the application behaves: currencies, units, accounting dimensions and approved status values. Master data describes relatively enduring business entities such as suppliers, customers and items. Open transactions describe unfinished work: an unpaid invoice, an outstanding order or stock available at the transition date. These layers have dependencies. Loading an order before its supplier or currency exists creates a relationship problem, even when the source file is readable.

Keep historical reporting separate from operational migration. A business may need old invoices for reference without needing to recreate every past transaction in the new posting engine. Agree retention, access and reporting requirements with the responsible specialists. Archiving is a decision about future access, not permission to delete required records.

Design identifiers and matching deliberately

Choose stable identifiers that do not change when a name, address or salesperson changes. Preserve old identifiers in a controlled crosswalk so support teams can trace a new record back to its source. Do not use a telephone number as the sole customer key: companies change numbers, and branches can share them.

Duplicate detection should produce candidates for review rather than automatically merging similar names. Two suppliers can have similar names and different bank accounts; two customer records can represent separate branches with different billing arrangements. Record who approved each merge and what happens to related open orders. Keep sensitive source files in restricted project storage and use masked samples in demonstrations.

Work through a concrete mapping

Imagine a hypothetical distributor with an item purchased as a box of twelve and sold individually. Its source spreadsheet contains quantity 20 without identifying the unit. The data owner must decide whether this means twenty boxes or twenty pieces. The migration team should not infer the answer from an item description.

Create an explicit mapping for purchase unit, sales unit, inventory unit, conversion factor and rounding rule. Test a purchase receipt, a partial sale and a return using that item. Reconcile the resulting stock in the base unit. A correct opening quantity is insufficient if the next transaction immediately distorts it.

Build a repeatable migration rehearsal

• Freeze a versioned source extract and record its extraction time.
• Validate required fields, allowed values and referential relationships before loading.
• Quarantine rejected rows with an understandable reason and an accountable owner.
• Load dependencies in a documented order using supported import interfaces.
• Compare source and target totals, then sample relationships and operational outcomes.
• Rerun the same package and verify that it updates or skips records as designed instead of creating duplicates.

A rehearsal needs realistic volume and a measured duration. Record extraction, transformation, loading and reconciliation separately; otherwise a fast import can hide several days of manual cleanup. Track rejected records by business impact, not only by percentage. One rejected supplier with urgent unpaid invoices can matter more than hundreds of inactive contacts.

Reconciliation needs more than row counts

Check counts by entity and status, financial totals by currency, stock by item and location, and links between headers and lines. A balanced total can conceal two offsetting mistakes. Sample high-value and unusual records separately, including negative balances, inactive suppliers with open transactions and products with multiple units.

Database constraints can enforce uniqueness and valid references in a custom system, but they cannot decide whether a supplier is commercially legitimate or a conversion factor is sensible. PostgreSQL's constraints documentation explains the technical boundary; business reconciliation remains essential regardless of database choice.

Decide what blocks release

Define unacceptable discrepancies before the final rehearsal. Examples include an unexplained opening balance, an orphaned order line or an unapproved duplicate merge. Assign a decision owner for less serious exceptions, with a correction deadline and a documented operational workaround. Do not label unresolved issues as accepted merely because the migration window is closing.

After launch, keep ownership active. Monitor duplicate creation, rejected integrations and unauthorized changes to sensitive fields. The practical next step is a readiness workshop covering one supplier-to-invoice journey and one item-to-stock journey. PRAESYNX enterprise software services can support requirements and integration discussions; the checklist here is a planning aid, not a guarantee of migration success.