# 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.

Product: content-central · Versions: 7.x · Audience: catalog-administrator · Time: 15 minutes · Last verified: 2026-09-05

Canonical: https://help.ademero.com/content-central/administration/catch-duplicate-documents-with-field-checks

**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

1. 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.**

2. 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.)

3. 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](/content-central/reports-and-exports/create-a-report) 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.

## What's next

- [Set up your first catalog, fields, and document types](https://help.ademero.com/content-central/administration/set-up-catalogs-fields-and-document-types)
- [Create a report](https://help.ademero.com/content-central/reports-and-exports/create-a-report)