Probe the firm’s books for an existing expense that would collide with a prospective payload. Useful before posting a scanned receipt.
Documentation Index
Fetch the complete documentation index at: https://docs.contazen.ro/llms.txt
Use this file to discover all available pages before exploring further.
POST /expenses when the source is unattended (OCR, recurring import, supplier sync). The response tells the UI whether to surface a confirmation dialog (“an expense from this supplier with this reference already exists — continue?”) instead of silently posting a duplicate.
The endpoint never modifies state. Match resolution mirrors the server-side detector used by the OCR + import flows.
supplier_id (preferred — Romanian companies often share name prefixes) or supplier_data with the resolved name/CUI from the receipt. The endpoint never auto-creates a supplier; if the supplier_data block doesn’t match an existing row, the supplier match is treated as missing and only reference-based matches are considered.
supplier_id is unknown. Resolved by CUI first (with RO prefix stripped), then by exact name match.name — supplier name as printed on the documentcui — supplier CUI / VAT number, with or without RO prefixlikely cross-supplier matches.YYYY-MM-DD. Combined with supplier + amount for strong matches.RON.match_type | Trigger |
|---|---|
exact | Same supplier + same reference |
strong | Same supplier + same date + amount within ±0.02 |
likely | Same reference under a different supplier (review before posting) |
exact and strong should usually block; likely deserves a confirmation but isn’t necessarily a true duplicate (e.g. invoice numbers reset per fiscal year across suppliers).
duplicate is null when no candidate matches. When populated, the id is the CzUid of the existing expense — fetch it via GET /expenses/{id} for the full record.
supplier_id nor supplier_data.name is providedread permission on expensesUse your API key (sk_live_xxx or sk_test_xxx)
Duplicate check result