The problem behind the system.
In a project-based construction business, reviewing an invoice involves more than comparing totals. The reviewer needs to understand the vendor, project, purchase order, prior billing and whether the contracted work is complete. Partial invoices and repeated line amounts make a guessed match especially unhelpful. The application brings these relationships into the review process.
- Invoice lines can share the same amount, so a matching rule must be able to return an ambiguous result.
- A project task and a financial record represent different responsibilities; completion must be propagated only to eligible linked records.
- Decision history is useful for investigation, but a logging failure should not prevent the underlying invoice transaction.
Our contribution
Matt Stirling and his business partner built the custom procurement application, integration logic and workflow controls. This is a joint OnSummit team contribution. The solution extends existing project-management and accounting platforms; the vendors provide the underlying scheduling, purchasing and accounting capabilities.
The decisions that shaped the work.
Allow the matching logic to say it is uncertain.
Two purchase-order lines can have the same pre-tax amount. A broad invoice tolerance cannot determine which line an invoice belongs to.
The matching service normalizes amounts to cents and searches within the selected purchase order. It links a line only when there is a unique matching subtotal, returning distinct no-match and ambiguous outcomes otherwise. Tests cover exact, ambiguous and negative matching scenarios.
Design consideration. A strict rule leaves some cases for review. That is preferable to hiding an unresolved relationship behind an arbitrary match.
Make completion a qualified input.
Project progress is relevant to a payable, but completing a task does not by itself establish that every financial condition has been satisfied.
A task-update handler propagates completion or reopening to eligible linked purchase-order lines. A separate Flow evaluates vendor and project consistency, completion, duplicates, tax, allocation and amount conditions, accumulating reasons for the review result.
Design consideration. Completion propagation is scoped to eligible links. The design does not assume every invoice participates in the same completion rule or can bypass an approval decision.
Keep the reasoning alongside the decision.
A status alone does not explain which conditions passed, which values differed or why a reviewer needs to investigate.
A dedicated logging service receives decision context from Flow, including reasons, expected and actual values, and variance. The review interface also brings related invoices and billed or remaining amounts into the same procurement context.
Design consideration. Logging uses guarded writes and capacity checks so it does not block invoice processing. This favors continuity of the business transaction over a guarantee that every diagnostic record is retained.
What the system delivers
- A custom procurement interface joining purchase-order candidates, related invoices and financial context.
- Explicit invoice-line matching that preserves ambiguous and unmatched results for review.
- Payment-readiness orchestration informed by eligible work-completion signals, with recorded decision context and approval routing.
Technical implementation
- Lightning Web Components and Apex controllers provide the procurement review interface and data access.
- Dedicated Apex services separate line matching, accounting rollups, completion propagation and decision logging.
- Salesforce Flow coordinates readiness conditions and approval handling around TaskRay and Accounting Seed records.