Business Relations maintains a complete, deduplicated register of business parties and the structure around them. It manages companies as customers, as suppliers, or as both at once, with their trading names, registration and tax identifiers, default currency, payment terms and classification. It maintains the people associated with each company, their roles, job titles and direct contact details, and the physical and postal locations a company operates from, whether a single registered address or a network of branches, delivery points and billing sites.

Around that core it captures the relationships between parties, parent and subsidiary structures, agents, intermediaries and introducers, and the full communication history: calls, meetings, emails and notes logged against the account and the individual. Every record carries ownership, status and lifecycle so that dormant, merged and blocked parties are handled explicitly rather than left to rot. Rich search, type filtering, bulk operations and clean Excel export make the register usable at scale, and server-side pagination keeps lists responsive whether the base holds hundreds of accounts or hundreds of thousands.

Conceptually the module rests on three ideas and the ties between them. The first is the account: the organisation you have a commercial relationship with. An account is more than a name and address. It carries a trading role that says whether the organisation is somewhere you send invoices, somewhere you receive them, or both, and it carries the financial defaults that role implies, the currency it settles in, the tax treatment that applies, and the terms on which it trades. Accounts are not flat. They form hierarchies, so a group and its subsidiaries, or a head office and its branches, are understood as related parts of one commercial whole.

The second idea is the person: an individual who acts for an account. People are attached to the accounts they belong to and described by the role they play there, the buyer, the finance contact, the site manager, so the same human being can be reached in the right capacity without being confused with the company itself. The third is the location: a real place tied to an account, distinguished by purpose, such as where deliveries go, where statements are sent, or where the business is legally registered. Binding these together is the relationship and interaction record, which turns a static directory into a living picture: who introduced whom, which parties are connected, and every logged exchange over time. Explaining the domain this way keeps the register meaningful to the business rather than reducing it to a list of fields.

The everyday flow is onboarding and maintenance. A new party is created once, checked against the existing base so duplicates are caught before they form, classified by role, and enriched with its people, locations and defaults. From that point the account is edited in place as circumstances change: a contact moves on, terms are renegotiated, a new delivery site opens, a subsidiary is acquired. Each change is an amendment to the single shared record, so downstream modules see the update immediately.

Other workflows operate on the structure itself. Accounts are merged when the same organisation has been entered twice, split or re-parented when a corporate structure changes, and blocked or retired when a relationship ends, all without losing the transactional history that references them. Communication is logged as it happens, giving any user a chronological account of dealings with a party. Throughout, every create, amend and delete is governed by fine-grained permissions and written to an immutable audit trail, so the register is not only correct today but demonstrably accountable over time.

Master data is only valuable if it is trustworthy, so the module invests heavily in integrity and control. Company codes are enforced as unique keys, and matching logic on name, registration number and address surfaces likely duplicates at the point of entry rather than after invoices have already diverged. The financial attributes that ride on each account, currency, tax code and trading role, are validated against the suite's reference data, so a party cannot be saved with a tax treatment or currency the organisation does not recognise.

The role model distinguishes clearly between a customer, a supplier and a counterparty that is both, which lets the same organisation be billed and paid without the two sides of the relationship interfering. Data quality is measurable: incomplete or stale records are visible, and enrichment such as live invoice counts against each debtor and creditor gives immediate business context next to each name. Access is mediated by ability-based permissions on every operation, mutations are audited without exception, and export is controlled, so the register meets the governance and traceability expectations that finance, compliance and data-protection functions place on the system of record for who the organisation deals with.

Business Relations is the party layer the rest of the suite is built on, and it is deliberately unopinionated about any single use so every module can rely on it. Marketing and Sales draws its accounts, contacts and opportunities from here, so a lead becomes a customer without re-keying. Accounting reads the same companies as its debtors and creditors, inheriting currency, tax code and terms directly, which keeps accounts receivable and accounts payable aligned to one definition of each party. Financial Services treats these records as its counterparties, so exposures and settlements point at the same entities the rest of the business recognises.

Service, billing, contracts and procurement all resolve their parties through the same master, which means a change made once, a corrected address, a new finance contact, a blocked account, propagates everywhere it matters. Because the register is shared rather than copied, the suite avoids the reconciliation problem that plagues systems where each function keeps its own customer list. Business Relations is what lets a quote, an invoice, a support case and a payment all agree, without argument, on exactly who the other party is.

AI Workers are first-class users of Business Relations, working through the same permissions and audit trail as people. They answer conversational questions against the register, so a user can ask which customers in a region trade in a given currency, or which suppliers lack a finance contact, and receive a grounded answer drawn from live data. They execute actions within their authority: creating and updating accounts, attaching contacts and locations, logging communication and running the deduplication and enrichment routines that keep the base clean.

They watch the register for anomalies and exceptions, flagging probable duplicates, accounts missing a tax code or currency, contradictory hierarchy links and parties that have gone dormant, and they raise these before they cause downstream errors. They extract structured party data from inbound documents and correspondence, business cards, letterheads, supplier onboarding forms, and turn it into proposed records for review. They provide decision support, summarising the history and standing of a relationship on request. And they act as review and approval nodes in workflows, so the creation of a new supplier or the merging of two accounts can be routed through an AI Worker that checks completeness and consistency before a change to the shared master is committed.