> ## Documentation Index
> Fetch the complete documentation index at: https://docs.antei.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Validation Logic

> How Antei validates structured and imported data before it is persisted into the organization’s workspace.

<Icon icon="circle-check" size={26} color="#4B5563" />

# Validation Logic

Antei applies structured, multi-layered validation to every record ingested from integrations or file uploads. This ensures your organization only works with complete, de-duplicated, and jurisdiction-ready data — reducing errors and increasing audit risk coverage.

***

## Why This Matters

* Prevents downstream compliance failures
* Surfaces incomplete or mismatched records early
* Enables consistent reporting and reconciliation
* Ensures controlled deduplication and data ownership
* Keeps your organization’s tax posture clean and defensible

***

<Steps>
  <Step title="1. Schema Validation">
    Each incoming record is validated against Antei’s internal schema:

    * **Required fields** (e.g. `contact_id`, `amount`, `jurisdiction`) must be present
    * **Field types** must conform (e.g. number, enum, ISO date)
    * **Conditional rules** (e.g. `country` required if `tax_applied`) are enforced

    ❗ Invalid records at this stage are immediately flagged and not processed further.
  </Step>

  <Step title="2. Entity Normalization & Component Breakdown">
    Valid records are decomposed into sub-entities (e.g., `Transaction`, `Product`, `Contact`, `Invoice`, `TransactionOp`) and mapped to Antei's internal data registry.

    * Mappings are config-driven and aligned with the source system
    * Each component inherits sync metadata and classification
    * Nested objects are flattened for processing

    📌 Example: One invoice may contain multiple transaction ops and line-item products.
  </Step>

  <Step title="3. Deduplication & Matching Engine">
    Antei applies a **weighted deduplication algorithm** that combines:

    * **Fuzzy Matching** — For loosely matching names, addresses, etc.
    * **Structured Field Scoring** — For fields like tax ID, country, and external references
    * **Threshold Score** — ≥ 90% similarity flags a match as **Unprocessed** (needs user override)
    * **New Object Creation** — If similarity is \< 90%, a new record is auto-created

    Deduplication is applied both:

    * At the **entity level** (e.g., `Product`, `Contact`)
    * At the **final transaction compilation stage**
  </Step>

  <Step title="4. Mapping & Link Validation">
    Antei checks relationships to ensure:

    * Each entity references a valid `product_id`, `contact_id`, or `jurisdiction_id`
    * Linkages are consistent with existing org-scoped records
    * Duplicate relationship mappings are avoided

    Example: A transaction line referencing a deleted product will be flagged for review.
  </Step>

  <Step title="5. Classification & Enrichment">
    Antei auto-applies enrichment tags such as:

    * **Tax classification** (e.g. exempt, taxable, reverse charge)
    * **Entity role** (e.g. supplier, customer, tax authority)
    * **Sync metadata** (e.g. `source`, `timestamp`, `entity_type`)

    These enrichments power downstream logic like taxability rules and country-specific filings.
  </Step>

  <Step title="6. Completeness & Final Checks">
    A final check ensures all mandatory fields and linked entities are present.

    If anything is incomplete, the entity is marked as:

    * **Unprocessed** — Requires manual resolution
    * Logged in dashboards (e.g. `Unprocessed Products`, `Unprocessed Transactions`)
    * Skipped from downstream flows until corrected
  </Step>

  <Step title="7. Manual Override & Reprocessing">
    Users can resolve unprocessed items via the UI:

    * Fill in missing fields
    * Override and reassign to correct entities
    * Re-run validation post-manual mapping

    ✔️ Once approved, these records are stored as processed and marked clean.
  </Step>

  <Step title="8. Final Persistence & Usage">
    Successfully validated records are committed to your workspace:

    * Structured by module (`Transactions`, `Products`, `Contacts`, etc.)
    * Linked to sync payloads and original metadata
    * Available for reconciliation, return generation, analytics, and audit trails
  </Step>
</Steps>

***

## Common Unprocessed Scenarios

| Entity          | Reason for Unprocessed                        | Example                               |
| :-------------- | :-------------------------------------------- | :------------------------------------ |
| **Transaction** | Missing `contact_id` or fuzzy match ≥ 90%     | Refund not linked to contact          |
| **Product**     | Tax classification missing or duplicate match | Imported product lacks `taxability`   |
| **Invoice**     | Entity missing or tax rate mismatch           | Invoice linked to unregistered entity |

***

## Logs & Observability

* Validation failures are logged per record
* Retry logic is applied for transient integration/API errors
* Metadata tags identify all skipped, unprocessed, and user-modified entries
* UI allows filtered download of failed records
* Validation logs are permanently attached to sync and ingestion records

***

## Summary

This layered validation pipeline combines **config-based extraction, fuzzy matching, and score-driven deduplication** to deliver **clean, connected, audit-ready data** for every jurisdictional workflow.

***

## Need Help?

For validation-specific help or field mapping support, contact [support@antei.com](mailto:support@antei.com).