In a review of 120 AP invoices this month, two vendors submitted near-duplicate AI-fabricated PDFs that slipped past OCR validation and our hash-based dedupe. We isolated them using bank account age under 90 days and SPF/DKIM header mismatches; what upstream control is preventing submissions for you — template fingerprinting at intake or vendor portal liveness checks?
We’re stopping most of these with PDF-structure fingerprinting at intake: hash stable traits like producer string, font subset patterns, and xref style per vendor and compare to their baseline using pdfid/pdf-parser (PDF Tools | Didier Stevens). It catches AI-generated PDFs before OCR, but vendor Acrobat upgrades can trip it, so we only roll a new baseline after a quick manual check — would pairing this with your liveness check be overkill?
Upstream, we block at onboarding: open-banking account-owner match and bank ‘account open date’, so anything under 90 days or a name mismatch never submits. We also require a 10-second portal liveness check on first payout, which cut fake vendors about 70%; if you can’t hit bank APIs, micro-deposit name match per Nacha’s account validation rule works: https://www.nacha.org/rules/account-validation. @james_k84 your PDF traits are a good backstop, but the real win was stopping these at the gate.
@marcus_cain84 your structure hash is solid; we added a render-compare gate: rasterize page 1 at fixed DPI and SSIM it against the vendor’s last good baseline, which flags ‘near-duplicate’ AIs that rewrap text layers — like spotting a forged painting by brushstroke, not the signature. Caveat: false positives jump right after legit template refreshes, so we tie baseline resets to change tickets. Do you also lock the compare to the header region to keep CPU down?