Keeping documents in order: required metadata and duplicate protection

Where document chaos comes from

Document chaos rarely starts with one big mistake. It is usually the small things: an invoice added twice because it reached two people, a contract saved without its signing date, a supplier's name typed three different ways. Each seems harmless on its own, but together they mean that search returns incomplete or duplicated documents. The team stops trusting the archive and starts keeping its own spreadsheets next to it.

Keeping business documents in order comes down to two principles:

• every document is described in full, with the data you need to find it and account for it;
• every document is in the archive only once, not in several copies.

Instructions to the team alone cannot uphold them. The system's rules have to enforce them, with every save and without exception. Below we show how CONTMAN Archive does this.

Document metadata: the description you search by

Metadata is the data that describes a document. For an invoice, that might be its number, issuer, issue date and amount; for a contract, the parties, its number and the signing date. You search by metadata rather than by file name, so its quality decides whether the archive answers your questions or merely stores files.

In CONTMAN Archive, an administrator sets up the structure of the description:

• A document category is a named type of document, such as purchase invoices or sales contracts, together with the list of fields that describe every document in that category.
• A field definition is a reusable template with a set data type: text, whole number, decimal number, date and time, date, or a yes/no value. One definition can serve many categories, and the field can have a different name in each of them.
• The order of fields in a category is the order in which their values appear on the document and in search results.

The archive accepts only values that match the field's data type, its value list and its format. A text field can have a value list of up to 50 allowed values, so people pick a value from the list instead of typing it. A field with the NIP format accepts a Polish tax identification number (NIP), with or without spaces, dots and hyphens, as well as an EU VAT number, and stores every number in a single form, always with its country code. If a number is malformed, the form warns before saving, and for a Polish NIP it also warns when the check digit does not match.

A category and each of its fields can have a description of up to 2,000 characters. It is a good place for a short instruction: where to find the number, how to write the name, what not to put in the field. The description is read by the people adding documents, and by the AI assistant if your organisation uses one.

Required fields: no document enters the archive without its key data

The simplest way to avoid incomplete descriptions is not to let anyone save them. In CONTMAN Archive, an administrator marks chosen fields of a category as required. On the document form they carry an asterisk, and the description cannot be saved without their values.

The rule applies when a document is created, when it gets a description in another category, and with every edit: after the save, every required field must have a value. It also covers documents created by a workflow in CONTMAN Workflow. A workflow whose document-creation step does not fill the required fields cannot be published, and a document that would lack a required value at the moment it is created never enters the archive. Nor can a retention rule clear a required field.

A requirement applies from the moment it is switched on. The archive fills in nothing retroactively: descriptions saved earlier keep their gaps until their next edit, which must fill them. This lets you tighten the rules in a live archive without interrupting your team's work.

Which fields should be required? Those without which a document cannot be found, accounted for or linked to others. The rest can stay optional and be filled in later. Too many required fields tempt people to type anything just to be able to save, and that is chaos too, only better hidden.

Unique key: protection against duplicate documents

Duplicates are the second main source of chaos. The same invoice added twice means the risk of paying it twice, inflated reports and two places where people add information.

Why is one field not enough? Because an invoice number is unique only for its issuer. Several suppliers can issue an invoice numbered 15/10/2026, and each of them is a different document. If the archive rejected every repeated number, it would also reject genuine invoices. You recognise a duplicate only by the full set of data: the same number, the same issuer, the same date.

That is why a unique key in CONTMAN Archive can span several fields:

• In a category, you mark fields as part of the key. Together they form the category's key: the same combination of their values, for example the invoice number, the issuer's tax number and the issue date, can occur only once in the category across your whole organisation.
• A key field is always required, so nobody can get around the rule by leaving one of the fields empty.
• When the values of the key fields repeat a description already in the archive, the save is rejected. The form highlights the key fields, and a person allowed to read the category gets a link that opens the document which already has those values. Anyone without that permission gets no link, so the refusal does not reveal a document they cannot access.
• When a document is being created, the rejection covers the whole save: neither the document nor its file is created.
• The key checks every save, not just the form: a document added manually or via the API, a document created by a workflow, and a change to the description made by a workflow or a retention rule.
• When two people save the same invoice at the same moment, only one save goes through.

How the archive compares values

The key compares values in the form in which the archive stores them. In practice, this means:

• a tax number typed with hyphens and the same number typed without them are the same value, because a field with the NIP format stores every number in one form;
• 1.5 and 1.50 are the same value;
• the same moment recorded in different time zones is the same date and time;
• text is compared exactly and is case-sensitive, so "ABC" and "abc" are two different values (in fields flagged as sensitive data, case does not matter).

The last point matters when you design the key. If a text field is part of it, a value list keeps its values consistent, and document numbers are best copied exactly as printed.

When the key takes effect

You set the key once the category has been saved and the archive has prepared the field. Like a requirement, it applies from the moment it is switched on and checks only new saves: it does not report repeats among descriptions saved earlier. Removing a key field from the category narrows the key to the remaining fields, and removing the last one ends the rule.

How to design a category that keeps things in order

A few principles that work well when planning document categories:

1. Start by asking how you recognise the same document. The fields that answer that question form the key. For a purchase invoice, that is usually the number, the issuer's tax number and the issue date; for a contract, for example, its number and the counterparty's tax number.
2. Require only what is essential. A required field should make sense for every document in the category.
3. Standardise values at the source. Value lists and the NIP format make sure the same information always takes the same form, which helps both search and the key.
4. Describe the fields. One sentence of instruction in a field's description saves many corrections.
5. Set the rules early. Requirements and the key check new saves, so the sooner you switch them on, the fewer old gaps and repeats stay in the archive.

Order the system enforces

Required fields make sure every document is described in full, and the unique key makes sure it enters the archive only once. Both rules apply with every save, including when a workflow creates the document, so order no longer depends on whether someone happened to remember the instructions.

To learn who can see what in the archive, read our post on secure document storage. Book a demo of CONTMAN Archive, and we will show you how required fields and the unique key work in practice.