Supplier Invoice Control and Purchasing Intelligence System
Budget: €250 – €750 EUR
⸻
1. Purpose and Business Objective
The purpose of this system is to serve as a central invoice control, buying price management, and purchasing intelligence platform.
The system must:
• Automatically receive supplier invoices by email
• Validate invoices line by line against historically correct buying prices
• Detect pricing, discount, and quantity errors
• Support controlled resolution of invoice mismatches
• Handle credit notes (full and partial)
• Maintain a permanent, central catalogue of buying prices
• Store purchase quantities and purchase amounts
• Provide dashboards and reporting for finance and management
• Be usable on both desktop and mobile (responsive web application)
The system replaces:
• Google Sheets used for buying prices
• Manual PDF invoice checking
• Ad-hoc supplier dispute handling
• Fragmented purchasing insights
⸻
2. Core Design Principles (Mandatory)
Developers must respect the following principles:
1. Invoice validation is the core function
2. Buying prices are immutable (append-only)
3. Full historical traceability is required
4. Invoices and credit notes are never edited
5. Explicit human approval is required for price changes
6. Mobile is for overview and decisions, desktop for configuration
7. The system must reflect real supplier behavior
⸻
3. High-Level Architecture
The system must be delivered as a single web-based application with:
• Backend API
• Relational database
• Email ingestion service
• PDF / OCR processing
• Responsive frontend (mobile-friendly)
• Role-based authentication
Deployment may be cloud-based. Technology choices can be proposed by the developer but must support the requirements below.
⸻
4. Functional Modules
⸻
4.1 Invoice Intake (Email-Based)
Requirements
• Dedicated invoice email inbox
• Automatic monitoring of incoming emails
• Automatic extraction of PDF attachments
• Permanent storage of original invoice PDFs
Metadata captured
• Supplier
• Invoice number
• Invoice date
• Currency
• Email reference
• Original PDF file
Manual upload must exist as a fallback.
⸻
4.2 Invoice Parsing and Line Extraction
The system must extract from each invoice:
• Supplier SKU or product reference
• Product description
• Quantity
• Unit price
• Line total
• Invoice total
Notes:
• OCR must be used for scanned PDFs
• Supplier-specific parsing rules must be supported
• Unreadable or ambiguous lines must be flagged for review
⸻
4.3 Product and SKU Management
Product Model
• Stable internal product ID
• Canonical product name
• Free-text comments / notes (e.g. SKU changes, packaging changes)
SKU Mapping
• Supplier-specific SKUs
• Valid-from and valid-to dates
• Historical SKU changes supported
• Comments per SKU mapping
SKU changes must not break historical invoice matching.
⸻
4.4 Buying Price Catalogue (Permanent)
Buying Price Records
Each price record must contain:
• Product
• Supplier
• Buying price (net or discount-based)
• Currency
• Valid-from date
• Valid-to date (nullable)
• Created timestamp
• Created by
• Optional note / reason
Rules
• Prices are never edited or deleted
• New prices create new records
• Previous price records are automatically closed
• Invoice validation uses the price valid on the invoice date
This catalogue replaces Google Sheets entirely.
⸻
4.5 Invoice Validation Engine (Core Logic)
For each invoice line, the system must:
1. Match the line to a product via SKU mapping
2. Retrieve the correct buying price valid on the invoice date
3. Calculate expected unit price
4. Calculate expected line total
5. Compare expected vs invoiced values
Validation Rules
• Missing or incorrect discounts
• Incorrect unit prices
• Quantity mismatches
• Mathematical inconsistencies
• Rounding tolerance handling
• Unknown products or SKUs
Output
• Line-level validation result
• Invoice status:
• Received
• Validated
• Needs review
• Disputed
• Approved
• Closed
• Total deviation amount
⸻
4.6 Invoice Mismatch Resolution Workflow (Critical)
The system must define how humans resolve mismatches.
Mismatch Types
A. Supplier Error
Examples:
• Wrong price
• Missing discount
• Wrong quantity
Handling:
• Invoice marked “Disputed”
• Discrepancy summary generated
• Supplier contacted
• Credit note or corrected invoice expected
• Original buying prices remain unchanged
B. Legitimate Price Change
Examples:
• Annual price update
• Contract renegotiation
Handling:
• Invoice flagged as “Price mismatch”
• System shows old price vs invoiced price
• User must explicitly choose:
• Reject price → dispute invoice
• Accept price → create new buying price record
⸻
4.7 Accepting a New Buying Price
If a user accepts a new price:
1. User confirms acceptance
2. Optional comment is entered (e.g. “2025 contract increase”)
3. System creates a new buying price record
4. Previous price is closed
5. Invoice is revalidated
6. Invoice moves to “Approved”
Price acceptance must:
• Be logged (who, when, why)
• Never overwrite historical prices
⸻
4.8 Credit Notes and Corrections
Requirements
• Credit notes are separate documents
• Linked to original invoice
• Support:
• Full invoice credits
• Partial line credits
Rules
• Original invoice is never modified
• Credit notes adjust net payable amount
• Partial credits reduce purchase quantities and amounts
• Invoice lifecycle reflects resolution status
⸻
4.9 Purchase Ledger (Amounts and Quantities)
For every validated invoice line, store:
• Supplier
• Product
• Quantity purchased
• Unit buying price
• Line amount
• Invoice date
Credit notes create negative adjustments.
This enables:
• Supplier purchase volume analysis
• Product purchase volume analysis
• Period-based purchase reporting
• Bought vs sold comparisons (future)
⸻
4.10 Supplier Communication (Email Generation)
The system must support:
• Generating emails to suppliers
• Pre-filled subject and body
• Attachment of original invoice
• Attachment of discrepancy summary
• Editable before sending
• Full communication audit trail
⸻
5. Dashboard (Front Page)
The dashboard must be the default landing page.
Key Metrics
• Invoices processed (period)
• Invoices with errors
• Invoices awaiting review
• Total deviation detected
• Total credited / recovered amount
• Purchase amount (period)
• Units purchased (period)
Visual Elements
• Invoice status breakdown
• Supplier error frequency
• Purchase volume trends
Dashboard must be mobile-friendly and read-optimized.
⸻
6. Reporting and Analytics
Supplier Reports
• Total purchase amount
• Total units purchased
• Error frequency
• Average buying price trends
Product Reports
• Units purchased over time
• Buying price history
• Supplier share
Export to CSV / PDF required.
⸻
7. User Roles and Permissions
Minimum roles:
• Admin (full access)
• Finance / Purchasing (operational)
• Read-only (management)
Role-based access control required.
⸻
8. Mobile vs Desktop Usage
Mobile
• Dashboard
• Invoice review
• Approve / dispute
• View purchase metrics
• Add short comments
Desktop
• Buying price management
• SKU mapping
• Supplier setup
• Detailed invoice analysis
• Reporting
⸻
9. Non-Functional Requirements
• Secure authentication
• Audit logging of price changes and approvals
• Data backups
• Performance suitable for scaling invoice volumes
• Clean, professional UI
⸻
10. Suggested Build Phases
Phase 1 – MVP
• Email invoice intake
• Invoice parsing
• Buying price catalogue
• Validation engine
• Mismatch resolution workflow
• Dashboard
• Purchase ledger
Phase 2 – Enhancements
• Supplier email generation
• Advanced reporting
• Supplier-specific parsing optimization
• Notifications
Freelancers should quote per phase.
⸻
11. Evaluation Criteria for Developers
When requesting quotes, ask candidates to explain:
• How they will handle PDF variability
• How price history integrity is enforced
• How partial credit notes are handled
• How mismatch resolution is implemented
• How mobile usability is ensured
⸻
12. Feature Completeness Check
All essential features are included:
• Invoice control
• Price governance
• Purchase intelligence
• Supplier communication
• Auditability
Out of scope for now:
• Stock management
• ERP posting
• Payment execution
⸻
Final Note
This is a financial control system, not a simple automation script.
The scope above is intentionally lean but complete, and suitable for long-term operational use.
1. Purpose and Business Objective
The purpose of this system is to serve as a central invoice control, buying price management, and purchasing intelligence platform.
The system must:
• Automatically receive supplier invoices by email
• Validate invoices line by line against historically correct buying prices
• Detect pricing, discount, and quantity errors
• Support controlled resolution of invoice mismatches
• Handle credit notes (full and partial)
• Maintain a permanent, central catalogue of buying prices
• Store purchase quantities and purchase amounts
• Provide dashboards and reporting for finance and management
• Be usable on both desktop and mobile (responsive web application)
The system replaces:
• Google Sheets used for buying prices
• Manual PDF invoice checking
• Ad-hoc supplier dispute handling
• Fragmented purchasing insights
⸻
2. Core Design Principles (Mandatory)
Developers must respect the following principles:
1. Invoice validation is the core function
2. Buying prices are immutable (append-only)
3. Full historical traceability is required
4. Invoices and credit notes are never edited
5. Explicit human approval is required for price changes
6. Mobile is for overview and decisions, desktop for configuration
7. The system must reflect real supplier behavior
⸻
3. High-Level Architecture
The system must be delivered as a single web-based application with:
• Backend API
• Relational database
• Email ingestion service
• PDF / OCR processing
• Responsive frontend (mobile-friendly)
• Role-based authentication
Deployment may be cloud-based. Technology choices can be proposed by the developer but must support the requirements below.
⸻
4. Functional Modules
⸻
4.1 Invoice Intake (Email-Based)
Requirements
• Dedicated invoice email inbox
• Automatic monitoring of incoming emails
• Automatic extraction of PDF attachments
• Permanent storage of original invoice PDFs
Metadata captured
• Supplier
• Invoice number
• Invoice date
• Currency
• Email reference
• Original PDF file
Manual upload must exist as a fallback.
⸻
4.2 Invoice Parsing and Line Extraction
The system must extract from each invoice:
• Supplier SKU or product reference
• Product description
• Quantity
• Unit price
• Line total
• Invoice total
Notes:
• OCR must be used for scanned PDFs
• Supplier-specific parsing rules must be supported
• Unreadable or ambiguous lines must be flagged for review
⸻
4.3 Product and SKU Management
Product Model
• Stable internal product ID
• Canonical product name
• Free-text comments / notes (e.g. SKU changes, packaging changes)
SKU Mapping
• Supplier-specific SKUs
• Valid-from and valid-to dates
• Historical SKU changes supported
• Comments per SKU mapping
SKU changes must not break historical invoice matching.
⸻
4.4 Buying Price Catalogue (Permanent)
Buying Price Records
Each price record must contain:
• Product
• Supplier
• Buying price (net or discount-based)
• Currency
• Valid-from date
• Valid-to date (nullable)
• Created timestamp
• Created by
• Optional note / reason
Rules
• Prices are never edited or deleted
• New prices create new records
• Previous price records are automatically closed
• Invoice validation uses the price valid on the invoice date
This catalogue replaces Google Sheets entirely.
⸻
4.5 Invoice Validation Engine (Core Logic)
For each invoice line, the system must:
1. Match the line to a product via SKU mapping
2. Retrieve the correct buying price valid on the invoice date
3. Calculate expected unit price
4. Calculate expected line total
5. Compare expected vs invoiced values
Validation Rules
• Missing or incorrect discounts
• Incorrect unit prices
• Quantity mismatches
• Mathematical inconsistencies
• Rounding tolerance handling
• Unknown products or SKUs
Output
• Line-level validation result
• Invoice status:
• Received
• Validated
• Needs review
• Disputed
• Approved
• Closed
• Total deviation amount
⸻
4.6 Invoice Mismatch Resolution Workflow (Critical)
The system must define how humans resolve mismatches.
Mismatch Types
A. Supplier Error
Examples:
• Wrong price
• Missing discount
• Wrong quantity
Handling:
• Invoice marked “Disputed”
• Discrepancy summary generated
• Supplier contacted
• Credit note or corrected invoice expected
• Original buying prices remain unchanged
B. Legitimate Price Change
Examples:
• Annual price update
• Contract renegotiation
Handling:
• Invoice flagged as “Price mismatch”
• System shows old price vs invoiced price
• User must explicitly choose:
• Reject price → dispute invoice
• Accept price → create new buying price record
⸻
4.7 Accepting a New Buying Price
If a user accepts a new price:
1. User confirms acceptance
2. Optional comment is entered (e.g. “2025 contract increase”)
3. System creates a new buying price record
4. Previous price is closed
5. Invoice is revalidated
6. Invoice moves to “Approved”
Price acceptance must:
• Be logged (who, when, why)
• Never overwrite historical prices
⸻
4.8 Credit Notes and Corrections
Requirements
• Credit notes are separate documents
• Linked to original invoice
• Support:
• Full invoice credits
• Partial line credits
Rules
• Original invoice is never modified
• Credit notes adjust net payable amount
• Partial credits reduce purchase quantities and amounts
• Invoice lifecycle reflects resolution status
⸻
4.9 Purchase Ledger (Amounts and Quantities)
For every validated invoice line, store:
• Supplier
• Product
• Quantity purchased
• Unit buying price
• Line amount
• Invoice date
Credit notes create negative adjustments.
This enables:
• Supplier purchase volume analysis
• Product purchase volume analysis
• Period-based purchase reporting
• Bought vs sold comparisons (future)
⸻
4.10 Supplier Communication (Email Generation)
The system must support:
• Generating emails to suppliers
• Pre-filled subject and body
• Attachment of original invoice
• Attachment of discrepancy summary
• Editable before sending
• Full communication audit trail
⸻
5. Dashboard (Front Page)
The dashboard must be the default landing page.
Key Metrics
• Invoices processed (period)
• Invoices with errors
• Invoices awaiting review
• Total deviation detected
• Total credited / recovered amount
• Purchase amount (period)
• Units purchased (period)
Visual Elements
• Invoice status breakdown
• Supplier error frequency
• Purchase volume trends
Dashboard must be mobile-friendly and read-optimized.
⸻
6. Reporting and Analytics
Supplier Reports
• Total purchase amount
• Total units purchased
• Error frequency
• Average buying price trends
Product Reports
• Units purchased over time
• Buying price history
• Supplier share
Export to CSV / PDF required.
⸻
7. User Roles and Permissions
Minimum roles:
• Admin (full access)
• Finance / Purchasing (operational)
• Read-only (management)
Role-based access control required.
⸻
8. Mobile vs Desktop Usage
Mobile
• Dashboard
• Invoice review
• Approve / dispute
• View purchase metrics
• Add short comments
Desktop
• Buying price management
• SKU mapping
• Supplier setup
• Detailed invoice analysis
• Reporting
⸻
9. Non-Functional Requirements
• Secure authentication
• Audit logging of price changes and approvals
• Data backups
• Performance suitable for scaling invoice volumes
• Clean, professional UI
⸻
10. Suggested Build Phases
Phase 1 – MVP
• Email invoice intake
• Invoice parsing
• Buying price catalogue
• Validation engine
• Mismatch resolution workflow
• Dashboard
• Purchase ledger
Phase 2 – Enhancements
• Supplier email generation
• Advanced reporting
• Supplier-specific parsing optimization
• Notifications
Freelancers should quote per phase.
⸻
11. Evaluation Criteria for Developers
When requesting quotes, ask candidates to explain:
• How they will handle PDF variability
• How price history integrity is enforced
• How partial credit notes are handled
• How mismatch resolution is implemented
• How mobile usability is ensured
⸻
12. Feature Completeness Check
All essential features are included:
• Invoice control
• Price governance
• Purchase intelligence
• Supplier communication
• Auditability
Out of scope for now:
• Stock management
• ERP posting
• Payment execution
⸻
Final Note
This is a financial control system, not a simple automation script.
The scope above is intentionally lean but complete, and suitable for long-term operational use.