A field is not understood simply because it exists in an ERP system, spreadsheet, or form. Its meaning needs a documented definition, owner, source, and update rule. In a small company, a business data catalog does not need to be a large document. Start with fields that affect decisions or repeatedly cause questions: which customer is active, when an order is confirmed, what stock is available for delivery, and what an invoice status means.
Without that agreement, two users can look at the same field and reach different conclusions. The issue is then not only data quality. It is unclear accountability for the business meaning of the data.
A business data catalog is a working glossary of important business terms and fields. Its purpose is to align people, process, and system around the same questions: what the data represents, where it comes from, who maintains it, and when it may be used for a decision.
For a small company, documenting every technical field is not practical. A first catalog can cover ten to twenty fields with the greatest operational effect. The selection criterion is simple: include a field when it affects money, timing, a customer commitment, inventory, reporting, or a recurring discussion between functions.
Common starting candidates include:
Do not begin with the database structure. Begin with decisions. If a production manager plans work based on material availability, the definition of available quantity takes priority over a rarely used administrative field. If accounting and sales read invoice status differently, that status belongs in the first edition of the catalog.
For every field, the catalog should provide a short answer to at least four questions.
The definition should describe business meaning, not only the name of a screen or column. For example, a "confirmed delivery date" may mean the date on which the company is committed to deliver to a customer after the order is confirmed. If the organisation uses another meaning, that meaning needs to appear in the definition.
Record what the field is not as well. This is often the fastest way to remove misunderstandings. An "order date" is not necessarily the date when an order became binding. It may be the entry date, receipt date, or document date. The catalog needs to name the selected meaning precisely.
The source is the system, transaction, form, or approved document where the data is created or officially maintained. In an ERP process, it is useful to state the official transaction, not only the module name.
A record might state: the source is a confirmed sales order in the ERP system; the field is entered in the sales transaction; the report only displays the value. This prevents a manual correction of an amount in a local spreadsheet without changing the source record.
If the data arrives through an integration, identify the source system, transfer direction, and point at which the ERP system takes responsibility. An integration does not by itself define a business source. The team needs to establish which record takes precedence when values differ.
The definition owner is accountable for business meaning, permitted uses, and rules for changing the definition. This role does not need to enter every record. Sales may enter a delivery date, while a sales manager or designated process role maintains the definition of order status and its transition rules.
Separate at least four types of accountability:
One person may hold several roles, especially in a small company. The important point is to record them, not to create a complex organisational model.
The update rule should cover the trigger, authorised role, permitted change, and decision trail. For example: a sales coordinator enters the confirmed delivery date when confirming an order; after a confirmation is sent to the customer, a change requires approval from the responsible sales role; the reason for the change remains in the record or a linked document.
A rule does not always require a technical block. It can be a process control. However, where the system supports constraints, it is useful to distinguish what the database or application validates from what remains a business rule.
The following format is sufficient for a first catalog edition. Each record can fit into a few lines in a shared document or work-management tool.
Field: Sales order status
Field: Available item quantity
Field: Supplier invoice due date
These examples are not universal definitions. A company needs to align them with its own contracts, processes, ERP configuration, and accounting practice.
Technical controls can prevent some errors. Data constraints can, for example, validate unique values, required fields, and relationships between records. PostgreSQL documentation describes constraints including UNIQUE , NOT NULL , primary keys, and foreign keys: PostgreSQL Constraints .
Such controls answer questions such as: does the same identifier already exist, is a required value missing, or does a record point to an existing related record? They do not decide whether sales may commit a date to a customer, when a status may change, or who approves an exception. Those business rules need separate definition in the catalog and process.
This distinction reduces two common errors. The first is expecting database validation to resolve an unclear process. The second is maintaining an important business rule only as a verbal agreement because it cannot be expressed through one technical constraint.
Start with a short workshop involving the people who enter data and the people who decide from it. For every candidate field, ask these questions:
Hypothetical scenario: sales marks an order as "ready", the warehouse reads that status as an instruction to dispatch, and accounting reads it as a condition for issuing an invoice. The catalog does not need to change the system immediately. It can first separate the meanings: "ready for dispatch", "dispatched", and "ready for invoicing", then assign owners and transition rules. Only then does it make sense to assess whether fields, statuses, or an integration need to change.
When misunderstandings extend across several functions, Business process screening can provide a structured starting point: identify decisions, official transactions, handoffs, and accountability points before larger ERP changes.
A catalog creates a maintenance obligation. A definition without an owner becomes outdated quickly, while an oversized catalog loses everyday use. It is therefore better to begin with a limited number of fields and set a review whenever a process, form, integration, or report used for an important decision changes.
One term can also legitimately have several values. "Customer" may refer to the contracting party, goods recipient, and payer. Rather than forcing these roles into one term, the catalog should state each role, the related field, and the permitted use.
A catalog does not replace access rights, accounting policies, contracts, or master-data quality. It is the shared place where the connection between those topics and a specific field becomes visible.
Before publishing the first catalog, check each record against this list:
Once the first catalog passes this check for several important fields, use it in everyday collaboration, alongside official ERP transactions and process changes. To connect the catalog with accountability, process steps, and operating rules, see the ORKA operating system .