Catch duplicate documents with field checks
Turn on per-field duplicate detection — the invoice-number-per-vendor scoping included — and know how it actually behaves at each surface: a warning at capture, a hard stop in the coding queue.
At the end of this guide, capturing an invoice number the system has already seen raises a flag before the duplicate files — and you'll know exactly how firm that flag is at each surface, because it varies, and the variance is the support question.
Turn it on
Open the field's editor (Administration > Catalogs & Document Types > the type > Fields — or Global Fields for the global definition) and tick Check for duplicate value on update/commit.
For the classic AP case, add the scoping switch beneath it — Limit duplicates by other field. — and pick the companion field. This is the setting that makes the feature match reality: invoice number 1001 exists at every vendor, so an unscoped check cries wolf all day. Scoped by Vendor, "duplicate" means what AP means by it: this vendor's 1001, twice. (The scoping switch lives on document-type fields, not on the global definition.)
Save the field.
How it behaves — surface by surface
| Where | Behavior |
|---|---|
| Capture page | A Duplicate Values Found dialog before upload: "The following fields have values that already exist in other documents. You can proceed anyway or go back and change the values" — with the field, the value, and how many documents carry it. Cancel or Proceed Anyway: a warning, deliberately, because sometimes the second document is legitimate |
| Coding queue commit | A hard stop — "A document with this value already exists" and the commit doesn't happen. No proceed-anyway: by indexing time, a duplicate is presumed a mistake |
| Editing a filed document's fields | The check doesn't run in the current interface — a duplicate introduced by after-the-fact editing won't be flagged |
That third row is the honest print: duplicate checking guards the intake doors. If after-filing edits are a real duplication vector in your shop, the duplicate-scoped reporting angle — a report grouped by the checked field — is the audit that catches what the door check can't.
Design notes from the field
- Check the field people actually key — the invoice number, the claim number — not derived or optional fields; a check on a field capture leaves blank checks nothing (blank values are exempt by design).
- The count in the warning is information: "3 document(s)" existing tells the operator this isn't a fat-finger, it's a pattern — worth a look before proceeding anyway.
- Auto-increment fields manage their own uniqueness — the duplicate-check switches don't apply to them, by design.
Success check: capture the same test invoice twice. The second capture stops at Duplicate Values Found naming your field and value; proceed anyway, then try the same trick through the coding queue and meet the hard stop. Now you know both behaviors before your users ask about either.