How Execura was tested against a real procurement problem—and what the investigation actually proved
Accounts payable teams rarely struggle because they cannot compare two numbers. The difficult part is reconciling what was ordered, received, and invoiced while preserving context, handling exceptions, involving the right human when necessary, and maintaining evidence of what happened.
This case study examines how Execura was tested against that problem.
The goal was not to build an accounting system or an ERP replacement. The goal was narrower:
Can Execura provide a reliable workflow and evidence layer around invoice/PO reconciliation?
The investigation ultimately exposed missing procurement infrastructure, a historically inconsistent database schema, several runtime defects, a concurrency vulnerability, and an important distinction between technical capability and business policy.
After those issues were addressed and independently verified, the backend workflow was validated with 117/117 tests passing.
The Problem
A typical procurement transaction involves at least three pieces of information:
Purchase Order
We ordered 10 units at $100 each.
Goods Receipt
We actually received 10 units.
Supplier Invoice
The supplier billed us for 10 units at $100 each.
When all three agree, the transaction can proceed.
But real operations produce exceptions:
- The invoice price differs from the PO.
- The supplier invoices more units than were ordered.
- The invoice covers goods that have not been received.
- Only part of the order has been delivered.
- Multiple documents must be reconciled.
- Someone needs to decide what to do when the numbers don’t agree.
- The organization needs to know what was compared and who resolved the exception.
The important problem is therefore not simply:
“Can we compare three documents?”
It is:
“Can we turn that comparison into a controlled, auditable business workflow?”
1. Starting With Reality, Not Features
The investigation began with real-world evidence and an audit of Execura’s existing capabilities.
The initial assessment found that Execura already contained pieces of the required infrastructure:
- purchase orders
- suppliers
- workflow execution
- human intervention
- audit logging
- evidence
- tenant isolation
- generic reconciliation capabilities
But the procurement domain itself was incomplete.
The expected procurement entities included:
- purchase orders
- purchase order lines
- goods receipts
- goods receipt lines
- supplier invoices
- supplier invoice lines
Several of those tables did not exist in the live database.
Worse, the database history contained an inconsistency: migration history indicated that a procurement migration had been applied, while the expected tables were absent.
That discovery changed the direction of the project.
Rather than pretending the existing schema was sufficient, the investigation stopped and reconstructed the actual database state.
2. The Schema Reality Check
The investigation found multiple procurement representations in the codebase.
There was:
- A simplified procurement representation.
- Another procurement subsystem with different semantics.
- A low-code JSON representation used for proof-of-concept functionality.
- Broken or incomplete routes referring to tables that did not exist.
- Existing customer-invoice tables that were not supplier invoices.
This last distinction was particularly important.
Execura already had:invoices invoice_lines
But those represented customer billing / accounts receivable.
They could not simply be reused for supplier invoices.
The investigation therefore established a hard domain boundary:Customer billing invoices invoice_lines ≠ Procurement supplier_invoices supplier_invoice_lines
That prevented an apparently convenient shortcut from contaminating two different business domains.
3. Building the Missing Procurement Foundation
The controlled solution extended the existing procurement model rather than creating another parallel procurement engine.
The resulting domain included:purchase_orders └── purchase_order_lines goods_receipts └── goods_receipt_lines supplier_invoices └── supplier_invoice_lines
The implementation also added the necessary relationships, indexes, tenant isolation policies, and audit triggers.
Existing routes were corrected where they referenced the wrong schema.
The objective was deliberately narrow:
Build only the procurement foundation required to validate three-way reconciliation.
No accounting engine.
No payment system.
No ERP integration.
No OCR.
No AI invoice processing.
No inventory system.
4. Three-Way Matching
With the domain foundation in place, Execura’s three-way matching service could operate on real procurement records.
The matching process compares:
Purchase Order
What was ordered.
Goods Receipt
What was received.
Supplier Invoice
What was billed.
The system captures a point-in-time snapshot of the relevant documents and calculates the comparison.
For example:PO 10 × $100 Receipt 10 × received Invoice 10 × $100
produces:MATCH
Whereas:PO 10 × $100 Receipt 10 × received Invoice 10 × $120
produces:PRICE_MISMATCH
The important design decision was that line identity and price comparison are separate concerns.
Lines are aligned using:product + unit of measure
and price is compared afterward.
This prevents a supplier changing the price from being incorrectly interpreted as an entirely different line.
5. The Investigation Found Real Defects
The first implementation was not simply accepted because the tests appeared green.
Hostile verification found a serious defect in snapshot handling.
The matching service created a deeply frozen snapshot and then attempted to modify aggregate values afterward.
That produced:TypeError: Cannot assign to read only property
The defect was repaired by calculating the aggregate values before freezing the snapshot.
Additional runtime defects were discovered and fixed, including:
- incorrect handling of grouped invoice lines
- price being included in the line matching key
- receipt currency being referenced despite not being part of the approved schema contract
- incorrect handler imports
- missing resolution behavior
- incorrect role-based assignment handling
- template-variable resolution issues
- workflow instance UUID normalization
- duplicate intervention creation under concurrency
This was one of the most important parts of the investigation.
The objective wasn’t to demonstrate that the first implementation looked good.
It was to find where it broke.
6. The Concurrency Problem
The most significant workflow defect appeared later.
The original exception mechanism used:SELECT "Is there already an active assignment?"
followed by:INSERT assignment
That appears safe when one worker is running.
But two workers can execute simultaneously:Worker A Worker B SELECT → none SELECT → none INSERT INSERT ↓ ↓ assignment A assignment B
The result could be two active interventions for the same workflow step.
That is exactly the kind of defect that ordinary sequential tests miss.
The solution was to move the critical guarantee into the database.
A partial unique index was introduced:(tenant_id, step_instance_id, assignee_id)
for assignments whose status is not:completed cancelled
Now concurrent workers cannot create two active assignments for the same semantic intervention.
The database becomes the final authority rather than relying solely on application timing.
Concurrent testing subsequently demonstrated exactly one active intervention.
7. Exceptions Become Human Decisions
A mismatch does not necessarily mean the system should make the business decision itself.
Execura’s workflow separates:Detection ↓ Classification ↓ Human intervention when required ↓ Resolution ↓ Workflow continuation
For example:PRICE_MISMATCH PO: $100 Invoice: $120
creates a blocking exception and routes the intervention to the appropriate role.
An authorized person can then resolve the exception.
The resolution does not rewrite the original procurement documents.
Instead, it becomes an additional business event.
That distinction is important.
The original evidence remains:What the documents said
while the resolution records:What the human decided Who decided it When they decided it Why
8. Authorization Was Tested
The resolution mechanism was tested with different actors.
Process initiator
Allowed to resolve according to the existing authorization model.
ap_supervisor
Allowed to resolve procurement exceptions.
Unauthorized user
Rejected.
The unauthorized attempt itself is recorded in the audit trail.
This gives the workflow a clear distinction between:Someone attempted to resolve an exception
and:An authorized person actually resolved it
9. The Six Operational Scenarios
The final E2E validation exercised the major reconciliation states.
Scenario A — Exact Match
PO: 10 × $100 Receipt: 10 Invoice: 10 × $100
Result:MATCH → workflow continues → no intervention → evidence preserved → audit recorded
Scenario B — Partial Delivery
PO: 10 Receipt: 4 Invoice: 4
Result:PARTIAL_DELIVERY → MATCH_WITH_WARNINGS → workflow continues
This behavior is intentional.
The approved Case #4 contract defines partial delivery as a non-blocking warning because phased deliveries are expected.
This became an important lesson during validation: the acceptance test itself initially contained an incorrect assumption.
The implementation was ultimately shown to conform to the authoritative procurement contract.
Scenario C — Price Mismatch
PO: 10 × $100 Receipt: 10 Invoice: 10 × $120
Result:PRICE_MISMATCH → workflow WAITING → human intervention
Scenario D — Quantity Mismatch
PO: 10 Receipt: 10 Invoice: 12
Result:QUANTITY_OVER_INVOICE → workflow WAITING → human intervention
Scenario E — Missing Receipt
PO: exists Invoice: exists Receipt: missing
Result:no false match → validation failure → workflow does not incorrectly approve the transaction
Scenario F — Over Receipt
PO: 10 Receipt: 12 Invoice: 12
Result:QUANTITY_OVER_RECEIVED → workflow WAITING → human intervention
10. Evidence Is Part of the Result
A reconciliation result is useful only if somebody can later understand how it was reached.
Execura preserves a point-in-time match snapshot containing relevant information such as:
- purchase order
- receipt
- supplier invoice
- quantities
- prices
- tolerance configuration
- classification
- matching timestamp
The workflow additionally preserves:
- process instance
- step instance
- intervention
- resolver
- resolution timestamp
- resolution decision
- resolution reason
- audit events
The result is therefore not merely:
“Mismatch.”
It can reconstruct:
What was compared, what differed, what decision was made, who made it, and when.
11. Source Documents Remain Untouched
Another important invariant was tested throughout the E2E lifecycle.
The matching process does not rewrite:
- purchase orders
- purchase order lines
- goods receipts
- goods receipt lines
- supplier invoices
- supplier invoice lines
The validation compared source records before and after matching, exception creation, resolution, and workflow continuation.
Business data remained unchanged.
This gives the system a clean separation between:Source business records
and:Reconciliation evidence + decisions
12. Tenant Isolation
The system is multi-tenant, so reconciliation cannot become a mechanism for accessing another organization’s documents.
Cross-tenant attempts were tested against:
- workflow instances
- purchase orders
- receipts
- supplier invoices
- assignments
- matching operations
The application-level tenant boundaries prevented cross-tenant access.
The procurement tables also have PostgreSQL RLS policies.
One limitation remains: the E2E tests ran under the PostgreSQL postgres superuser, so RLS enforcement under a production-style non-superuser database role was not independently verified.
That is an infrastructure/test-environment evidence limitation, not a demonstrated cross-tenant defect.
13. Customer Invoices Stay Separate
The investigation deliberately tested another potential failure mode.
Execura already contains customer billing:invoices invoice_lines
The procurement matching service must never accidentally consume those records.
The test created a customer invoice and then executed a supplier invoice reconciliation.
The result:Customer invoice unchanged Supplier invoice used by reconciliation
The three-way matching service references:supplier_invoices supplier_invoice_lines
not the customer billing tables.
14. What Is Actually Operational?
After all the phases, the backend can perform this lifecycle:Create PO ↓ Create PO lines ↓ Create goods receipt ↓ Create receipt lines ↓ Create supplier invoice ↓ Create invoice lines ↓ Start workflow ↓ Three-way match ↓ ┌───────────────┐ │ │ MATCH EXCEPTION │ │ ↓ ↓ Continue Assignment ↓ Human decision ↓ Resolution ↓ Continue ↓ Audit
This is a real backend workflow running against PostgreSQL—not a mock demonstration.
15. What Execura Does Not Claim
This case study does not establish that Execura is:
- an ERP
- an accounting platform
- an accounts-payable replacement
- a payment system
- an inventory-management system
- an OCR invoice-processing platform
- an AI invoice-processing system
- a complete procurement suite
- a reporting/KPI platform
The validated capability is narrower:
Execura can orchestrate procurement reconciliation as a controlled workflow, including three-way matching, exception routing, human resolution, evidence preservation, auditability, tenant isolation, retry handling, and concurrency protection.
That’s the claim supported by the investigation.
16. Operator Reality
There is another important limitation.
The backend workflow is operational, but the operator-facing frontend is incomplete.
The validation found no complete production UI for:
- purchase order creation
- goods receipt management
- supplier invoice management
- three-way match monitoring
- exception resolution
- procurement dashboards
The current capability can therefore be exercised through the backend APIs and workflow engine.
That distinction matters:
Backend capability: validated.
Complete operator product experience: not yet validated.
No frontend was built simply to make the case study look complete.
17. Final Validation
The final test accounting was:
Validation
Result
Procurement foundation
78/78
Three-way match runtime
10/10
Workflow integration
12/12
Concurrency protection
2/2
Phase 5 E2E
15/15
Total
117/117
The case went through multiple hostile reviews.
The investigation found and corrected:
- schema inconsistencies
- runtime matching defects
- immutable snapshot mutation
- line-alignment errors
- workflow integration defects
- authorization issues
- concurrent duplicate intervention creation
The final backend validation passed all 117 tests.
What This Case Actually Taught Us
The most valuable outcome wasn’t the three-way matching algorithm.
It was discovering the difference between a feature and an operational capability.
A three-way matching function can be written relatively quickly.
A reliable business capability requires considerably more:Domain model + Correct data boundaries + Deterministic matching + Exception semantics + Authorization + Human intervention + Concurrency control + Immutable evidence + Audit + Retry behavior + Tenant isolation + Operational workflow
And even after all of that, there is another layer:
Does the implemented behavior actually match the business policy?
The partial-delivery investigation demonstrated why that question matters. The initial Phase 5 test expected partial delivery to block the workflow. The authoritative Case #4 contract said the opposite. The investigation did not blindly change the implementation to satisfy the test; it traced the discrepancy back to the approved contract.
That is the kind of validation we want from Execura development:
Don’t build because a feature sounds useful.
Don’t trust a green test blindly.
Don’t trust an AI-generated implementation report blindly.
Instead:
Find the real problem → reproduce it → inspect the existing system → identify the smallest generic capability → build only what is missing → attack it → verify the complete workflow → document what is actually proven.
Case #4 Status
CLOSED — PASS
Validated capability: backend invoice/PO three-way reconciliation and controlled exception workflow.
Test result: 117/117 passing.
Known limitation: PostgreSQL RLS enforcement under a non-superuser application database role was not independently verified.