Engineering inside ClearMatch /
The data model, constraints and recovery decisions behind ClearMatch.
Match invoices against purchase orders and received quantities before an owner approves the exact revision.
Interface and interaction architecture
The React control centre sits alongside a PDF.js document renderer with its worker, fonts and support files served from the same origin. Attachments remain authenticated.
Three-way comparison as explicit rules
The reconciliation handler compares invoice SKUs with the purchase order, checks unit prices and ordered quantities, then aggregates distinct goods receipts. It emits named exception codes such as PRICE_MISMATCH and RECEIPT_SHORTFALL. The result is an inspectable set of line-level facts rather than a model-generated yes/no answer with hidden reasoning.
Exact totals with stated constraints
Whole quantities and prices are validated as integer strings. BigInt arithmetic calculates subtotal, tax and total, then compares the result with the declared invoice amount. Tax uses the implemented basis-point rounding rule and supported currencies have two decimals. Totals beyond the accepted bound fail explicitly; multi-rate or fractional-quantity accounting needs a separate design.
Identity and review boundaries
A supplier identifier plus invoice reference prevents a second ordinary reconciliation for the same invoice in the workspace. Receipt references must be distinct within the submitted record. Updates re-run the comparison and reset approval. The owner approves a matching version and digest only when the exception list is empty; another workspace cannot open its evidence.
Persistence without automatic posting
The local API persists documents, results and versioned change events using workspace-scoped records and idempotent operations. Source-file access is checked against the same user context. The exported PDF and CSV show status, amounts, exceptions and digest. There is no verified accounting-ledger connector or payment execution behind that local approval step.
Operating the product
Start with the public interface preview to explore overview and insights using example records. Open /dashboard for account-scoped metrics calculated from your saved records, or /desk for the underlying workflow.
Keep supplier IDs, invoice references and goods-receipt records consistent with the system of record. Resolve discrepancies with those records before changing reconciliation data.
After correcting documents, reload and inspect the new exception list and totals. An earlier approval should not be reused for the changed record.
When extraction leaves a field unknown, complete it from the document or responsible operator. Use manual entry when a provider is unavailable or the source must remain local.
Preserve attachments, reconciliation versions and exports together. Validate any future accounting connector with duplicate, retry, permissions and reversal tests before enabling writes.
Independent by construction
ClearMatch has its own application source, build configuration, local server, database, object store and session cookie. The fifteen applications reuse copies of a common foundation, but their operational data and credentials are independent. A shared dependency cache on this Mac saves disk space; each product includes a lockfile and a command to install its own dependencies.
Mutations validate the workspace and current record version. Approval binds the reviewed content digest; an idempotency key prevents an identical retry from becoming a second action. These controls are implemented in the server, alongside the product-specific rules described above.
A similar problem in your business?
Bring a real workflow, representative inputs and the result that needs to be reliable.
Shape a project brief