Country-aware fields
How postal codes and tax identifiers adapt to the country a record belongs to.
- Audience
- Administrators, CRM users, Procurement users, Finance users
- Permissions needed
- Organization settings
- Environment
- Production and staging
- Product version
- Current
- Last reviewed
- Owner
- Propulsive Product Team
Company and vendor records are country-aware: the address and tax fields offered are driven by the country the record declares, not by one global form.
How it works
For each supported country, a country rule pack declares:
- the postal code field label and format (PIN code, Postcode, ZIP code, Postal code, Postleitzahl - the local term, not an anglicised stand-in)
- the tax identifier the country uses (GSTIN/PAN in India, VAT registration number in the UK and Germany, EIN in the US, UEN in Singapore, ABN in Australia, Business Number in Canada, Tax Registration Number in the UAE)
Supported countries today include India, the United Kingdom, the United Arab Emirates, the United States, Singapore, Australia, Germany and Canada. A record in a country with no pack keeps the generic fields.
Why it matters
Two reasons. First, validation: a postal code or tax number is checked against the format the country actually uses, so a wrong-shape identifier is caught at entry rather than at filing time. Second, reporting: tax returns and e-invoice flows read the tax identifier field that matches their country’s expectation - a GSTIN is found in the GSTIN field, not guessed from a free-text box.
Data quality
The presence of these country-correct identifiers feeds the Master Data Governance scores: a vendor missing the tax identifier its country requires shows against your data-quality score. That is a warning, not a block - you can transact before it is fixed, but the score keeps the gap visible.