Trading Parties are the master records that represent the suppliers, buyers, clients, and counterparties that appear on business documents processed through Docupath. They serve as both identification records and scoping boundaries, enabling the platform to match entities detected on documents to known party profiles, enrich extracted data with verified master data, and apply party-specific instructions and rules.

Trading Relationships, automatically generated links between two trading parties, add a further layer of specificity, allowing instructions and rules to be scoped to a particular bilateral trading context.

How It Works

Trading Party Records

A trading party is a master record containing identifying details for a business entity. Each trading party must belong to a sub-organization (mandatory) and can include the following fields:

Name, Address, Country - required fields
City, Postal code, VAT number, Registration number, GLN (Global Location Number), Email - optional fields
Other custom fields (not supported out-of-the-box, must be pre-configured by Docupath / partner)

Trading parties can be added manually by anyone with write access to Trading Parties, or created directly from the Document Review interface when a required party does not yet exist. Duplicate parties within the same sub-organization are prevented by the system.

Read access on Trading Parties also unlocks the Trading Party tab inside Instruction Builds, Transformations, Rejections and Customize Captured Fields. When an admin builds a custom role, the Trading Party row of those four modules stays greyed out, with an info note explaining why, until the role has read access on Trading Parties.

Duplicating Trading Parties Across Organizations

A trading party is created within a single sub-organization, but you can copy it, along with all of its details, into other organizations without re-entering the information.

On the Trading parties page, find the party's row and click the Copy trading party icon in the Actions column.
The Select organizations to add dialog opens, showing your organizations and their sub-organizations.
Choose one or more organizations or sub-organizations to copy the party into. You can:
- Use the search box to find a specific organization.
- Expand an organization to select individual sub-organizations.
- Select Select All to choose every organization.
Click Add to copy the trading party into the selected organizations, or Cancel to discard.

Trading Party Matching

During document processing, Docupath attempts to identify trading parties by searching the extracted document text against known party records under the relevant organization. The matching process uses:

Party Alternate Names - Keyword-style name variants added to a party profile (e.g., "ACME Ltd", "ACME Logistics")
Party Name - The primary registered name of the trading party

When a match is found, the party is assigned to the document and the system enriches relevant fields using that party's master data. If no match is found, the document is flagged for manual party selection during review. Minor differences in case or spacing are handled automatically during matching.

Alternate Names (Aliases)

Each trading party supports up to 20 alternate names, keyword-style variants that capture acronyms, former names, localized spellings, and subsidiary references. During processing, Docupath scans extracted text for these variants and auto-links the document to the correct trading party on match.

Trading Relationships

Trading Relationships are system-generated links between two trading parties. They are not created manually. The system automatically creates a relationship when:

An Instruction Build, Transformation, or Rejection Rule is created referencing two specific trading parties (Party A + Party B)
A document is processed and two trading parties are successfully detected and matched

Once created, a trading relationship enables relationship-scoped behavior, the most specific level in Docupath's precedence hierarchy.

Scope Precedence

Trading parties and relationships sit at the top of the precedence hierarchy:

Trading Relationship (Party A + Party B) - highest priority
Trading Party (only Party A or only Party B)
Organization
Country
Global - lowest priority

This precedence applies across Instruction Builds, Transformations, and Rejection Rules.

Document Review: Party Assignment

When parties are not automatically detected:

The document is flagged with "No Trading Parties Found. Please select the trading parties in the document."
Reviewers can manually select parties from the available records. Adding a new party from the review screen requires write access to Trading Parties
Reviewers can override detected parties or swap Party A and Party B (useful for credit notes where buyer/seller roles are reversed)

Organization-Level Override

Sub-organizations can define an override trading party that automatically sets the Primary Party for every document routed to that sub-organization, regardless of what the document content indicates.

Supported Configurations and Options

Configuration	Detail
Party fields	Name, Address, City, Postal Code, Country, VAT, Registration Number, GLN, Email, Other Custom Fields
Alternate names	Up to 20 per trading party
Matching method	Alternate name match then Party name match (case-insensitive)
Relationship creation	Automatic via Instruction Build, Transformation, or Rejection Rule creation, or document processing
Override trading party	Configurable per sub-organization
Party deletion	Soft delete - historical references preserved, no new assignments
Access control	Write access to Trading Parties allows create, edit and delete.

Other Technical Specifications

Parameter	Limit
Maximum alternate names per party	20
Maximum name length	255 characters
Maximum address length	255 characters
Maximum city length	100 characters
Maximum postal code length	10 characters (letters and numbers, with single spaces or hyphens between them)
Maximum extra (custom) field length	255 characters
Maximum alternate name length	150 characters
Duplicate prevention	Enforced within same sub-organization
Relationship deduplication	Enforced for same primary/secondary combination

Notes

Field length limits on trading party fields are enforced in both the web interface and the API.

Party creation, edits, deletions, and document-level party changes are all logged in Activity Logs.

Known Limitations and Edge Cases

A trading party must belong to a sub-organization; it cannot exist at the parent organization level
Duplicate parties are prevented within the same sub-organization but may exist across different sub-organizations
If two trading parties share an overlapping alternate name, ambiguous matching may occur - variant lists should be refined to ensure unique identification
Deleted trading parties are soft-deleted: historical documents retain their references, but the party cannot be newly assigned
If a document mentions multiple organizations in its content, Docupath selects the most appropriate match based on alternate name lists; persistent ambiguity requires variant refinement
Override trading party applies unconditionally to all documents in the sub-organization - conditional logic is not supported at this level
Trading Relationships cannot be manually created or deleted; they are system-managed based on instruction, rule, and document processing events