Information Checklist¶
Applies to: All subscriptions
Purpose¶
Collect everything Complifly needs from the customer, once, in a usable form. Incomplete or malformed data supplied late is the most common cause of an implementation slipping without anyone being able to point to a decision that caused it.
Audience¶
Implementation consultants running collection, and the customer's project manager assigning owners.
Prerequisites¶
- Prerequisites overview
- A named owner on the customer side for each data domain below
Steps¶
1. Organisation and registrations¶
| Item | Format | Quality criterion |
|---|---|---|
| Legal entity names | Text, exactly as registered | Must match the registration character for character. A near-match causes rejections that look like a mapping fault |
| Every GSTIN in scope | 15-character identifier, one per row | Include dormant registrations. An omitted registration that later issues a document produces an out-of-scope rejection |
| Registered address per GSTIN | Address line, location, PIN code, state code | State code must match the GSTIN's own state prefix |
| Dispatch-from addresses, where different | Same fields | Only where goods leave from somewhere other than the registered address |
| PAN | 10 characters | Consistent with the GSTIN |
| TAN | If the TDS module is licensed | — |
2. Users and access¶
| Item | Format | Quality criterion |
|---|---|---|
| User list | Name, email, job function | Email must be the one the user actually reads; account activation depends on it |
| Intended role per user | One of the platform roles | Map from job function, not from job title. See Roles and Permissions |
| GSTIN access per user | Which registrations each user may see | Users at a single site rarely need every registration |
| Segregation-of-duties decision | Enforced or relaxed | A control decision, made by the customer, recorded in writing |
| Administrators | At least two | One administrator is a single point of failure at the worst possible moment |
3. Master data¶
What you must collect depends entirely on which modules you have licensed. A customer running only e-Invoice and e-Way Bill loads far less than one running Invoice Generation, because in the first case the party and item details arrive inside each document from the ERP — there is no customer or item master to populate.
| Item | Module | Format | Quality criterion |
|---|---|---|---|
| Organisation, GSTINs and registered addresses | All subscriptions | Legal name, GSTIN, address, PIN, state code | Must match the registration record exactly. This is the only master every subscription needs |
| Customer master | Invoice Generation only | Name, GSTIN(s), addresses, credit terms | Several GSTINs per customer is normal; set the default deliberately |
| Item master | Invoice Generation only | Code, description, HSN or SAC, unit, default rate | HSN and SAC must be the correct length for the code family |
| Rate master | Invoice Generation only | Rate per HSN or SAC, with effective dates | Effective dates matter — a rate applied a day early is a real defect |
| Numbering series | Invoice Generation only | Prefix, format, current position | Must be unique per GSTIN per financial year |
| Transporter identifiers | e-Way Bill | Transporter ID per carrier used | Not a master you load — there is no transporter master. These are entered on the bill, so the dispatch team simply needs the IDs to hand |
| TAN and deductor details | TDS only | TAN, deductor category | One per TAN where a group holds several |
| Privacy notices and purposes | Data Privacy only | Notice text, processing purposes | Drafted by the customer's legal advisers, not the implementer |
If you have only e-Invoice and e-Way Bill, the first row is the only one you must supply. Buyer names, item descriptions and tax amounts all travel in the ERP payload and are validated on arrival — they are not loaded in advance.
Reference data that everyone needs — state codes, supply types, HSN and SAC code lists, unit codes, transport modes, cancellation reasons — is shipped with the platform. You do not collect or load it.
Master data quality is the strongest predictor of a smooth go-live for the modules that use it. A malformed GSTIN or a wrong-length HSN code does not fail quietly — it fails at the moment a user is trying to issue a real document.
4. ERP samples¶
| Item | Format | Quality criterion |
|---|---|---|
| A sample payload per document type | The ERP's own native format, unmodified | Do not hand-clean it. The mapping must be built against what the ERP really emits, including its quirks |
| The ERP's date format | Worked example | An ambiguous date format is the most common mapping defect |
| Code values used by the ERP | Value list per coded field | For example, how the ERP represents an invoice versus a credit note |
| Multi-line examples | At least one document with several lines | Single-line samples hide array-handling problems |
| Edge cases | Export, reverse charge, zero-rated, discounts, rounding | These are where mappings break, and they are always found late if not supplied early |
Ask for the edge cases explicitly. Customers supply a clean domestic invoice by default, and every difficult mapping question then arrives during user acceptance testing.
5. Business rules and decisions¶
| Decision | Options | Who decides |
|---|---|---|
| Segregation of duties | Enforced or relaxed | Customer's finance control owner |
| Automatic IRN generation on ingest | On or off | Customer. Off by default — it is a legal act performed without a person present |
| Write-back to the ERP | On or off | Customer and ERP team. Off by default; not retrospective |
| Document type routing | Default or overridden | Customer's tax lead |
| Approval thresholds | Values, if the Invoice Generation Module is licensed | Customer's finance lead |
| Notification recipients | Distribution lists | Customer. Use a list, never an individual's mailbox |
6. Branding and print¶
| Item | Format | Quality criterion |
|---|---|---|
| Logo | Image file | Legible at print size; a large logo scaled down often is not |
| Print template preferences | Per GSTIN if they differ | — |
| Statutory declarations or footers | Text | Supplied by the customer's tax lead, not drafted by the implementer |
Validation¶
Do not accept a data set as complete until it passes these checks. Validating on receipt costs an hour; validating during user acceptance testing costs a week.
| Check | Method | Pass condition |
|---|---|---|
| GSTIN format | Check every value is 15 characters with the expected structure | No malformed values |
| GSTIN state consistency | Compare each GSTIN's state prefix with its stated state code | They agree on every row |
| Legal names match registration | Spot-check against registration records | Exact match, including punctuation and spacing |
| HSN and SAC lengths | Check each code against the valid lengths for its family | No wrong-length codes |
| Duplicate parties | Group by GSTIN | No GSTIN appears under two different party records |
| Rate effective dates | Inspect the earliest and latest dates | Sensible; no rate effective before its statutory date |
| ERP samples parse | Load each sample into the mapping tool | Every sample parses and every intended field is addressable |
| Edge cases present | Count the sample types supplied | At least one export, one reverse charge and one multi-line document |
| Users have real email addresses | Send a test message | Delivered, not bounced |
| Two administrators exist | Count | At least two, at different individuals |
Troubleshooting¶
| Symptom | Cause | Action |
|---|---|---|
| Master data arrives in an unusable shape | Format not agreed before extraction | Supply the template first. Re-extracting is cheaper than cleaning by hand |
| Mapping works in testing and fails on real documents | Samples were hand-cleaned before being supplied | Insist on raw output from the ERP, quirks included |
| Rates apply from the wrong day | Effective dates supplied without timezone or convention agreed | Confirm the convention explicitly and re-verify a sample rate after loading |
| Users cannot activate their accounts | Email addresses are shared mailboxes or aliases that nobody reads | Collect individual addresses; account activation depends on a person receiving the message |
| Rejections citing a party's registration status | Cancelled or suspended counterparty GSTINs in the master data | Flag and clean before go-live; verification results age, so re-check close to the date |
| Difficult mapping questions surface during user acceptance testing | Edge cases not supplied during collection | Request them explicitly by name. Customers do not volunteer them |
| An unlisted GSTIN issues a document after go-live | Dormant registration omitted from the list | Onboard it. This is why the list must include dormant registrations |
| The logo prints illegibly | High-resolution image scaled down, or an unsuitable aspect ratio | Test a real print before go-live, not a screen preview |
Related Articles¶
- Technical Prerequisites
- Commercial and Statutory Prerequisites
- Master Data Setup — loading what is collected here
- User Creation
- Roles and Permissions — mapping job functions to roles