Match Results

Match results are presented per document, with the top 5 candidates ranked by weighted confidence score. Each candidate includes a confidence score and field-level evidence showing which comparisons contributed to the match: the strategy used for each field (exact, fuzzy, date_range, or numeric_range), the individual field score, and the actual values that were compared on both sides. This transparency makes it straightforward to verify correct matches and investigate false positives.

Each result also carries a per-result status: matches scoring at or above the configuration's auto-accept threshold are marked matched, borderline results in the review band (from 0.4 up to the threshold) are marked review, and documents with no viable candidate are marked no_match. A reviewer decision then overwrites the status with approved, rejected, or overridden. The API reports confidence as a fraction between 0 and 1; the app displays it as a percentage.

Reviewing and approving matches

When reviewing results, focus on documents where the top candidate has a confidence score between roughly 50% and 85%: these are the borderline cases that benefit most from human judgment. High-confidence matches (above the auto-accept threshold) are usually correct, while very low scores typically indicate no valid match exists in the reference data.

Results from smart runs and AI-resolve passes carry additional fields. ai_decision records the LLM's verdict on a candidate — match, no_match, or uncertain — alongside ai_reasoning explaining it, and routing records the three-way strategy routing (auto_commit, auto_reject, or review_band). This means a reviewed result tells you the full story: how the deterministic pass scored it, how the strategy routed it, what the AI resolver concluded and why, and finally what the human reviewer decided.

Approved matches flow downstream into delivery pipelines, where they can be included in structured exports alongside extraction data. Rejected matches are excluded from future consideration for that document, which helps the system learn from your decisions when running subsequent matching passes.

curl -s https://api.talonic.com/v1/matching/runs/RUN_UUID/results \
  -H "Authorization: Bearer $TALONIC_API_KEY"

# Response:
# {
#   "data": [
#     {
#       "id": "e7f8a9b0-…",
#       "document_id": "f0e1d2c3-…",
#       "document_filename": "Invoice_ACME.pdf",
#       "matched_reference_row_id": "a1b2c3d4-…",
#       "confidence": 0.87,
#       "status": "review",
#       "evidence": {
#         "candidates": [
#           {
#             "fields": [
#               { "field": "vendor_name", "strategy": "fuzzy", "score": 0.92,
#                 "source_value": "Acme Corp", "target_value": "ACME Corporation" },
#               { "field": "total_amount", "strategy": "numeric_range", "score": 1.0,
#                 "source_value": "12450.00", "target_value": "12450.00" }
#             ]
#           }
#         ]
#       }
#     }
#   ]
# }

curl -X POST "https://api.talonic.com/v1/matching/runs/RUN_UUID/results/RESULT_UUID/review" \
  -H "Authorization: Bearer $TALONIC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "status": "approved" }'

# status: "approved" or "rejected". The decision overwrites the
# engine status (matched / review / no_match) on the result.

Consider a practical example: you receive an invoice from "Acme Corp" with a total of $12,450 dated 2025-03-15. The matching engine returns the top candidate as "ACME Corporation" in your reference data with 87% confidence. The evidence view shows the vendor name scored 92% via fuzzy match (handling "Corp" vs "Corporation"), the amount scored 100% via numeric_range, and the date scored 78% via date_range because the reference shows a PO date of 2025-03-10, within the 7-day tolerance. You can quickly verify the match is correct and approve it, sending the linked record downstream.