# Invoice Validation Project

## Architecture

This project implements an invoice validation engine.

Validation modules are implemented separately and must remain separate.

Current validation modules:

1. Vendor Validation
2. Tax ID Validation
3. Bank Validation
4. Date Sanity Check
5. Payment Terms Validation
6. Tax Validation
7. Completeness Check

## Rules

* Do not merge validations into one large function.
* Keep business logic inside each validation module.
* The orchestration layer should only coordinate execution.
* Vendor Validation runs first.
* Any validation module that depends on vendor master data must receive resolved_vendor_id from Vendor Validation.
* Pass resolved_vendor_id to all downstream validations that require vendor-specific lookups or checks.
* All validation configuration is stored in platform_configs.json.
* Validation functions receive platform_configs as input.
* Do not hardcode operational thresholds.
* Use the SDD as the source of truth.
* Tenant isolation must always be respected.

## Expected Outcome

After all validation modules are verified against the SDD:

* Create a lightweight orchestrator.
* The orchestrator should load platform_configs.json once.
* The orchestrator should call validators in the correct order.
* The orchestrator should pass outputs from one validator to downstream validators where required.
* The orchestrator should aggregate risk flags and advisory flags.
* No business logic should be implemented in the orchestrator.


## Matching Project Rules

- Matching runs after validation.
- Do not run all match types for every invoice.
- First decide the match type using a routing step.
- Routing should decide:
  - 2-way match
  - 3-way match
  - contract match
  - no match
- Keep match routing separate from match logic.
- Keep each match type in its own file.
- The matching orchestrator should only connect routing and match modules.
- Do not put matching business logic inside the orchestrator.
- Final output should include validation result + matching result.