Accounts Receivable Invoices

Goal & Scope

Created: 18.01.2026

Goal: Enable users to upload/send outgoing invoices (Accounts Receivable) to Orcha for processing, tracking, and management alongside existing Accounts Payable functionality.

Scope:

Why: Complete financial document management requires tracking both incoming (AP) and outgoing (AR) invoices. This enables:

Key Differences: AP vs AR Invoices

Aspect Accounts Payable (Current) Accounts Receivable (New)
Direction Received FROM suppliers Sent TO customers
We are Recipient/Buyer Issuer/Seller
Key party Issuer (supplier) Recipient (customer)
Payment focus When WE need to pay When CUSTOMER should pay
Validation Validate supplier VAT Validate our VAT matches tenant
Cost center Assign to cost center Not applicable
Accruals Expense accrual Revenue recognition
GL accounts Expense accounts Revenue accounts

Data Model Changes

-- Current enum
CREATE TYPE document_type AS ENUM ('invoice');

-- New enum  
CREATE TYPE document_type AS ENUM ('invoice', 'ar-invoice');
-- OR more explicit:
CREATE TYPE document_type AS ENUM ('ap-invoice', 'ar-invoice');

Option B: Add Direction Field

ALTER TABLE document ADD COLUMN invoice_direction TEXT; -- 'incoming' | 'outgoing'

Structured Data Schema

The existing StructuredData schema can be reused, but field interpretation differs:

Field AP Interpretation AR Interpretation
issuer Supplier (external) Our company (should match tenant)
recipient Our company Customer (external)
cost-center Assign expense N/A for AR
service-category Categorize expense Categorize revenue
bu-code DATEV expense code DATEV revenue code (if applicable)

Processing Pipeline Changes

1. Ingestion (com.getorcha.erp.ingestion)

2. Extraction (com.getorcha.workers.ingestion.extraction)

3. Validation (com.getorcha.workers.ingestion.validation)

4. Post-Processing (com.getorcha.workers.ingestion.post-process)

UI/UX Changes

1. Navigation Sidebar (layout.clj)

;; Current structure:
[:li "Accounts Payable"]
[:li "Settings"]

;; New structure:
[:li "Accounts Payable"]
[:li "Accounts Receivable"]  ;; NEW - between AP and Settings
[:li "Settings"]

2. New Routes

3. AR List Page

Similar to AP list but with adapted columns:

AP Column AR Column
Supplier Customer
Total Amount Invoice Amount
Due Date Payment Due
Status Status
Validation Validation

Additional AR-specific columns (future):

4. AR Detail Panel

Swap emphasis of issuer/recipient:

AP Detail Panel:

AR Detail Panel:

Remove/Hide for AR:

Add for AR:

Implementation Phases

Phase 1: Basic AR Support

  1. Add ar-invoice to document_type enum (migration)
  2. Create AR list page route and handler
  3. Add AR nav item to sidebar
  4. Create AR upload endpoint (sets type to ar-invoice)
  5. Adapt detail page to handle AR display

Phase 2: Email Classification & Processing

  1. Build AP/AR classifier for email ingestion
  2. Add issuer-tenant validation check (reuse multi-entity logic)
  3. Skip cost center matching for AR
  4. Adapt tax compliance for AR perspective

Phase 3: Revenue Account Matching

  1. Support revenue accounts dataset loading
  2. Adapt AccountsMatcher to use revenue accounts for AR
  3. Adapt AccrualsMatcher for revenue recognition

Phase 4: AR Enhancements

  1. Payment status tracking
  2. Customer master data matching
  3. DSO analytics
  4. AR aging reports

Open Questions for Discussion

1. Classification Strategy

Manual Upload:

Email Ingestion:

2. Post-Processing Scope

Processor Run for AR? Notes
AccountsMatcher ✅ Required - use revenue accounts dataset
CostCenterMatcher ❌ Not applicable for revenue
AccrualsMatcher ✅ Adapt for revenue recognition
TaxComplianceAnalyzer ✅ Adapt for issuer perspective
UncertainValidationsResolver ✅ Still needed

3. Issuer Validation (Multi-Entity Support)

Requirement: Validate that AR invoice issuer matches one of the tenant's legal entities.

Approach: Reuse existing multi-entity support from AP:

4. Database Structure

Decision: Extend document_type enum with ar-invoice value.

5. Extraction Prompt

Decision: Reuse existing extraction prompt.

6. Revenue Account Matching

Requirement: Support revenue account matching for AR line items.

Implementation:

File Changes Required

Database Migrations

Backend (Clojure)

File Change
erp/ui/layout.clj Add AR nav item
erp/http/documents.clj New AR routes and handlers (or parameterize existing)
erp/http/routes.clj Register AR routes
workers/ingestion/validation.clj Add issuer-tenant validation (reuse multi-entity logic)
workers/ingestion.clj Skip cost center for AR, run revenue account matching
workers/ingestion/post-process/accounts.clj Support revenue accounts dataset
workers/acquisition/triage.clj Add AP/AR classifier after extraction
schema/structured_data.clj No changes needed (schema is direction-agnostic)

Frontend (CSS)

Success Metrics

  1. Functional: Users can upload AR invoices and view them separately from AP
  2. Extraction quality: Same extraction accuracy as AP invoices
  3. Performance: No degradation in processing time
  4. UX: Clear separation between AP and AR workflows

Dependencies

Risks & Mitigations

Risk Mitigation
Confusion between AP/AR Clear UI labeling, separate navigation
Wrong classification Allow reclassification, clear error messages
Extraction errors for AR Monitor quality, adjust prompt if needed
Performance impact Separate processing queues if needed