Catch Duplicates and Silent Errors Before They Reach Approval

Every invoice that enters FinMark.ai is checked against history before any other processing happens. If the same invoice has been seen before, it gets flagged immediately and never enters the workflow. This catches the obvious duplicate cases — a vendor sending the same invoice twice, an AP clerk uploading the same file twice, an automated email forward triggering twice. These cases happen constantly in real AP workflows and they are the easiest fraud and error category to prevent.

It also catches near-duplicates: invoices with slightly different invoice numbers, amounts off by a few dollars, or split invoices that add up to the same total. These are the cases human reviewers miss because the volume is too high and the differences are too subtle.

AI extraction is great, but no AI is perfect. The small percentage of cases where the extraction is slightly off — a date misread, a tax amount off by a digit, a vendor name almost right — would cause real problems if they made it into ERP. Rule-based sanity checks catch these as a second line of defense.

The checks cover the categories that matter: date sanity (is the invoice date plausible), amount sanity (does the invoice total fall within historical norms for this vendor), vendor verification (is the vendor in the master, is the TIN valid), line-item totals (do the line items sum to the invoice total), tax math (does the tax match the rate and base), currency consistency, PO and GRN reference sanity, near-duplicate detection, and bank detail change detection.

The sanity checks are not just about catching extraction errors. They are also a fraud prevention layer. Bank detail change detection catches the most common Business Email Compromise (BEC) pattern. Vendor master verification catches vendor impersonation. Line-item math verification catches inflated invoices. Each check is a small control, but together they make a substantial difference in the fraud rate that reaches the approval stage.

The current implementation focuses on duplicate detection and rule-based sanity checks. ML-based anomaly detection for fraud — looking at vendor history patterns, unusual amounts, timing anomalies — is on the roadmap but not in production today. The deterministic checks above handle the highest-impact fraud categories and are production-tested at a major enterprise group.