Master Data Setup¶
Applies to: All subscriptions · Invoice Generation · Which modules do I have?
Purpose¶
Load the reference data documents are built from, and prove its quality before anything depends on it. Master data quality is the strongest single predictor of a smooth go-live.
Audience¶
The customer's data owner, with the implementation consultant.
Prerequisites¶
- Environment Preparation gate passed
- Data collected per Information Checklist
- A named data owner on the customer side
Steps¶
1. Validate before loading¶
Validating on receipt costs an hour; validating during user acceptance testing costs a week. Run these checks on the file, before anything is loaded:
| Check | Fail condition |
|---|---|
| Registration number format | Not 15 characters in the expected pattern |
| Registration and state consistency | The state prefix disagrees with the stated state code |
| Legal names | Do not match the registration record exactly |
| Classification code lengths | Wrong for their family — goods and services differ |
| Duplicate parties | One registration under two party records |
| Rate effective dates | Missing, or starting before their statutory date |
| Postal codes | Wrong length, or inconsistent with the state |
| Encoding | Non-ASCII names mangled |
2. Know which of this stage applies to you¶
This stage is mostly an Invoice Generation stage. How much of it you do depends on your subscription:
| Subscription | What you load here |
|---|---|
| e-Invoice and/or e-Way Bill only | Organisation, GSTINs and addresses only. Party and item details arrive inside each document from the ERP — there is no customer or item master to populate |
| Plus Invoice Generation | The above, then customer, item, rate and numbering masters |
| Plus TDS | The above, plus TAN and deductor details |
| Plus Data Privacy | The above, plus notices and processing purposes |
Reference data — state codes, supply types, HSN and SAC lists, unit codes, transport modes — ships with the platform. You neither collect nor load it.
3. Load in dependency order¶
Only the rows your subscription needs:
Organisation, GSTINs, addresses <- ALL subscriptions
|
v
Customers (with their GSTINs/addresses) <- Invoice Generation
|
v
Items (with classification codes) <- Invoice Generation
|
v
Rates (per classification, effective-dated) <- Invoice Generation
|
v
Numbering series <- Invoice Generation
|
v
TAN / deductor details <- TDS
Notices and purposes <- Data Privacy
Load a small sample first — twenty records — and verify it fully before loading the rest. A format problem found on twenty rows is an edit; found on twenty thousand it is a reload.
4. Verify what was loaded¶
Not that the load reported success — that the data is there and correct:
| Check | Method |
|---|---|
| Counts match | Records loaded equals records supplied, minus deliberate exclusions |
| Scoping correct | Records appear under the intended registration, and only there |
| Spot-check values | Open ten records and compare against the source |
| Search works | Find a record by the terms a user would actually type |
| Rates resolve | A test document picks up the expected rate |
The scoping check matters here specifically: data loaded under the wrong registration is invisible to the users who need it and visible to those who should not have it.
5. Verify counterparty registrations¶
Cancelled counterparty registrations cause government rejections at the worst possible moment. Verify the significant ones before go-live.
Verification results age. A registration verified today can be cancelled next month, so re-check before high-value supplies and periodically thereafter.
6. Establish ongoing ownership¶
Master data is not a one-time load. Name an owner for:
| Responsibility | Why |
|---|---|
| Adding new parties and items | It will happen weekly |
| Maintaining rates with effective dates | Rates change; a rate applied a day early is a real defect |
| Re-verifying counterparty registrations | Results age |
| Removing duplicates | They accumulate |
Validation¶
Gate: this stage is complete when all of these pass.
| Check | Pass condition |
|---|---|
| Pre-load validation passed | Every check in step 1 |
| Counts reconcile | Loaded equals supplied |
| Correctly scoped | Under the right registration, visible to the right users |
| Spot-checks pass | Ten records match the source exactly |
| Rates resolve | A test document picks up the expected rate for the expected date |
| Counterparties verified | Significant ones checked and active |
| A test document builds | Using real master data, and passes validation |
| Ownership assigned | A named owner for ongoing maintenance |
Rollback¶
| Situation | Action |
|---|---|
| Wrong file loaded | Remove the loaded records; correct the source; reload |
| Loaded under the wrong registration | Remove and reload under the correct one. Do not attempt to re-scope in place |
| Rates loaded with wrong effective dates | Correct them before any document uses them — a document already built on a wrong rate is a tax problem, not a data one |
| Partial load | Establish precisely what loaded, using a count that is not itself scope-dependent; then complete or reverse |
Master data is reversible while no document depends on it. Once documents are built and registered on it, correcting the master does not correct the documents.
Common mistakes¶
| Mistake | Consequence | Avoid by |
|---|---|---|
| Loading before validating | Bulk cleanup, or wrong data in production | Validate the file first |
| Loading everything without a sample | A format problem becomes a full reload | Load twenty records first |
| Legal names that do not match registrations | Government rejections that look like mapping faults | Match character for character |
| Classification codes with leading zeros stripped | Rejections at generation | Carry codes as text end to end |
| Rates without effective dates | Wrong rate applied, or none | Always supply dates and verify a sample |
| Not verifying counterparties | Rejections on the first real invoice to that customer | Verify the significant ones before go-live |
| Assuming load success means correct data | Wrong data, silently | Spot-check ten records |
| No ongoing owner | Data decays from go-live onward | Assign one now |
Troubleshooting¶
| Symptom | Cause | Action |
|---|---|---|
| Load reports success, records not visible | Loaded under a different registration, or the user lacks access | Check the scope first, then the user's access |
| Search does not find a record | Loaded differently from how users search | Spot-check the stored values |
| Wrong rate on a test document | Effective dates, or the item's default | Check dates before anything else |
| Duplicate party records | Two source systems, or inconsistent naming | Deduplicate on the registration number |
| Names show wrong characters | Encoding mismatch | Reload as UTF-8 |
| A test document fails validation on master data | The data is incomplete for what documents need | Fix the master, not the document |
Related Articles¶
- Information Checklist — collecting this data
- Validation Error Codes — what bad master data produces
- User Creation — the next stage
- Monthly Checks — ongoing hygiene