checafatura

Build a Generic Invoice Validation & Approval Application Build an MVP web application that automates the validation and approval of customer invoices against internal sales and order data. Product Context The initial use case is for a salesperson working for a wine brand. The salesperson sells products to multiple customers. Customers place orders and make payments, and invoices are subsequently submitted through an external platform. Today, the salesperson has to manually review each invoice before approving it. To make the approval decision, they compare information on the invoice against internal information they have about the customer, including: * Customer identity * Products sold * Quantities sold * Orders placed * Order values * Agreed prices * Amounts expected * Amounts already paid * Invoice amount * Relevant dates * Other customer-specific commercial information The invoice provides information such as the customer, invoice number, invoice date, line items, quantities, prices, taxes, and amount paid/invoiced. The salesperson manually compares these different sources and decides whether the invoice is correct and can be approved. The goal of this application is to automate that process. Important Constraint We currently DO NOT have access to: 1. The existing invoice approval platform 2. Its API 3. Real customer files 4. Real invoices 5. The exact format of sales/order data Therefore, build the system in a generic and modular way. Use mock/sample data initially, but design the architecture so that real data sources and the external approval platform can be connected later without rebuilding the application. Do not make the application wine-specific at the technical level. The wine sales workflow should simply be the first configuration/use case. Core Workflow The application should support the following workflow: Data Source → Invoice → Extraction → Matching → Validation → Decision → Human Review or Automatic Approval Step 1 — Customer Data Allow internal customer/order/sales data to be imported. For the MVP, support CSV and Excel uploads. Example fields: * Customer ID * Customer name * Order ID * Order date * Product/SKU * Quantity * Unit price * Total order value * Amount expected * Amount paid * Payment date * Salesperson The import system must use configurable field mapping rather than assuming fixed column names. For example: Client Name → Customer Name Account → Customer ID Total Sales → Order Value This allows different companies/files to use different schemas. Step 2 — Invoice Input Allow invoices to enter the application through: * Manual upload * PDF * Image * CSV/Excel * Manual entry Design an integration interface so that invoices can later be retrieved automatically from an external platform/API. Extract and normalize relevant invoice information into a standard internal structure. Example: * Invoice ID * Invoice number * Customer * Customer ID * Date * Order/reference number * Products * Quantities * Unit prices * Subtotals * Tax * Total * Amount paid * Currency Step 3 — Matching Automatically identify which customer and transaction/order the invoice relates to. Matching should use available identifiers such as: * Customer ID * Customer name * Invoice references * Order ID * Product * Date * Amount Create a confidence score for the match. Example: Customer match: 100% Order match: 100% Amount match: 99% Overall confidence: 99% If an exact identifier is unavailable, allow fuzzy matching while clearly indicating that the match is less certain. Step 4 — Validation Engine Create a configurable rules engine that compares invoice data with internal customer/order/sales data. Example rules: * Invoice customer matches customer record * Invoice references a valid order * Product/SKU matches * Quantity matches * Unit price matches * Invoice total matches expected amount * Amount paid matches recorded payment * Invoice date falls within an acceptable period * Invoice has not already been processed Rules should NOT be hard-coded. An administrator should be able to configure: * Which checks are required * Tolerances * Approval thresholds * Which failures block approval * Which failures create warnings * Which conditions require manual review For example: Invoice Total = Expected Total ± €1 → Pass Invoice Total difference > €1 → Manual Review Customer mismatch → Block Step 5 — Decision Engine Each invoice should receive one of three statuses: Approved All required checks pass and confidence exceeds the configured threshold. Needs Review The invoice may be legitimate but one or more checks are uncertain or outside tolerance. Rejected / Blocked A critical validation rule fails. Display the reasoning behind every decision. Example: Invoice #INV-1048 Customer: Restaurant ABC Invoice total: €4,850 Expected amount: €4,850 Recorded payment: €4,850 Customer match: PASS Order match: PASS Quantity check: PASS Price check: PASS Payment check: PASS Confidence: 99% Recommendation: APPROVE The system must never produce an unexplained approval or rejection. Human-in-the-Loop Approval For the MVP, do not actually approve anything on an external platform. Instead provide: * Approve * Reject * Request Review buttons inside the application. Record: * Decision * User * Timestamp * Validation results * Reason * Any manual override Later, an integration should be able to replace the internal Approve action with an API call or automated workflow against the existing invoice platform. Admin Portal Create an administrator area. The admin should be able to manage: Users * Create users * Disable users * Assign roles * Assign salespeople/customers Roles should initially include: * Admin * Approver * Viewer Data Sources Allow administrators to configure: * Customer files * Sales files * Order files * Payment files * Invoice sources Field Mapping Allow administrators to map incoming fields to the application’s standard data model. Validation Rules Allow administrators to configure rules without changing code. Each rule should have: * Name * Description * Data field * Comparison * Tolerance * Severity * Action when failed Approval Policy Allow configuration of automatic approval. Example: Automatically approve when: * All critical rules pass * No duplicate invoice exists * Customer confidence ≥ 95% * Order confidence ≥ 95% * Financial difference ≤ configured tolerance Otherwise send the invoice to manual review. Main Dashboard Create a clean dashboard showing: * Invoices awaiting review * Automatically validated invoices * Approved invoices * Rejected invoices * Exceptions * Total invoice value * Approval rate * Automation rate Allow filtering by: * Customer * Salesperson * Date * Status * Amount * Validation result Invoice Review Screen This should be the core screen of the application. Use a side-by-side comparison. Left side: Invoice Show the original invoice/document and extracted data. Right side: Internal Records Show the matched: * Customer * Order * Sales data * Payment information Below this, display a validation checklist. For example: ✓ Customer matches ✓ Order found ✓ Products match ✓ Quantity matches ✓ Price matches ✓ Payment found ⚠ Date difference: 4 days ✓ Total matches Then display: Recommended decision: APPROVE Confidence: 97% Allow the salesperson to approve, reject, or send the invoice for further review. Audit Trail Maintain a complete audit log. Every invoice should record: * Original source * Original document * Extracted information * Matched records * Validation rules executed * Result of every rule * System recommendation * Confidence score * Final human/system decision * User responsible * Timestamp * Overrides * Override reason The system should make it possible to understand exactly why an invoice was approved months later. Architecture Keep the system modular. Create separate components/services for: 1. Invoice ingestion 2. Document/data extraction 3. Data normalization 4. Customer matching 5. Order matching 6. Validation/rules engine 7. Decision engine 8. Approval workflow 9. External integrations 10. Audit logging 11. Authentication and permissions Create an integration/adapter layer. For example: InvoiceSourceAdapter CustomerDataAdapter OrderDataAdapter PaymentDataAdapter ApprovalPlatformAdapter Initially these can work with mock data and uploaded files. Later they should be replaceable with: * REST APIs * ERP systems * CRM systems * Accounting systems * Databases * Cloud storage * External invoice platforms without changing the core validation logic. Mock Data Because real files are currently unavailable, generate realistic mock data for: * 20 customers * 100 orders * Sales records * Payment records * 30 invoices Include examples of: * Perfect matches * Incorrect amounts * Incorrect quantities * Customer-name variations * Duplicate invoices * Missing orders * Partial payments * Overpayments * Date discrepancies * Product discrepancies This should make it possible to demonstrate all application states. Security Implement basic security from the beginning: * Authentication * Role-based access control * Secure file handling * Audit logging * Separation between organizations/tenants where appropriate * No silent modification of financial records Automatic approval should only happen when explicitly enabled by an administrator. MVP Priority Prioritize the following: 1. Dashboard 2. Invoice upload 3. Customer/order data upload 4. Configurable field mapping 5. Invoice extraction 6. Customer/order matching 7. Configurable validation rules 8. Pass/fail/warning results 9. Approval recommendation 10. Manual approve/reject/review 11. Admin configuration 12. Audit trail Do not over-engineer external integrations yet. Instead, create clearly defined interfaces/placeholders so they can be connected once access to the real invoice platform and customer files becomes available. UX Principle The product should feel like an AI-assisted financial operations reviewer, not simply a document viewer. A salesperson should be able to open an invoice and understand within seconds: What is this invoice? Which customer/order does it relate to? Does the invoice agree with our records? Are there any discrepancies? Can it safely be approved? Why is the system recommending this decision? The long-term objective is to move from: Manual invoice checking → AI-assisted validation → automated validation → automatic approval of low-risk invoices with human review only for exceptions.