Every entity in Antei (e.g. Transaction, Product, Contact, Invoice) has a field registry.
This includes:

• Field name (contact_id, tax_rate, amount)
• Data type (string, enum, date, etc.)
• Validation rules (e.g. required, format)
• Classification tags (e.g. sensitive, jurisdictional, calculated)

This registry forms the basis of mapping logic for integrations and manual imports.

For each integration (e.g. Stripe, Xero), a mapping configuration is defined:

• Source fields → Antei registry fields
• Includes type conversion and optional transformations
• Handles nested structures and system-specific edge cases

📌 Example: stripe_customer.id → contact_id, xero_invoice.total → invoice_total_amount

• Mapping logic accounts for record context:
  → E.g. a contact can be a customer, vendor, or tax authority
• Field roles adjust based on module (e.g. entity_id is optional for product uploads, required for transactions)
• Some fields (like country, currency, taxability) drive jurisdiction-specific rules

• All mappings are traceable
• Metadata such as source, extracted_id, and payload_origin are stored for each field
• This enables validation rollback, re-mapping, and audit trail traceability

Example:

{
  "mapped_field": "invoice_total_amount",
  "source": "stripe_invoice.total",
  "extracted_id": "abc-123",
  "mapping_version": "v1.4"
}

• The UI uses the field registry to dynamically generate mapping UIs and enforce constraints
• Field descriptions, types, and tooltips are directly derived from the registry
• Same rules are enforced for integrations, imports, and manual input