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-organisation (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 authorised users (Admin, Manager, or Custom roles) or created directly from the Document Review interface when a required party does not yet exist. Duplicate parties within the same sub-organisation are prevented by the system.
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 organisation. 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, localised 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 behaviour — 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)
Organisation
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 available records or add new parties directly
Reviewers can override detected parties or swap Party A and Party B (useful for credit notes where buyer/seller roles are reversed)
Organisation-Level Override
Sub-organisations can define an override trading party that automatically sets the Primary Party for every document routed to that sub-organisation — 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-organisation |
Party deletion | Soft delete — historical references preserved, no new assignments |
Access control | Admin, Manager, or Custom roles can create/edit/delete parties |
Other Technical Specifications
Parameter | Limit |
Maximum alternate names per party | 20 |
Duplicate prevention | Enforced within same sub-organisation |
Relationship deduplication | Enforced for same primary/secondary combination |
Integration Points
Document processing: Parties are detected and matched during AI extraction, triggering enrichment and the application of scoped instructions and rules
Scoping: Instruction Builds, Transformations, and Rejection Rules can be scoped to specific trading parties or trading relationships
Organisation structure: Trading parties belong to sub-organisations and are used for email ingestion routing via override trading party configuration
Enrichment: Matched trading parties enrich document fields with verified master data (name, address, VAT, etc.)
Audit trail: 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-organisation; it cannot exist at the parent organisation level
Duplicate parties are prevented within the same sub-organisation but may exist across different sub-organisations
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 organisations 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-organisation — 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
Related Articles
Integration, Implementation and Output — Parent article
Organizations — Organisation hierarchy and sub-organisation management
Overriding Trading Parties with Organizations — Override configuration detail
Instruction Builds — How party-scoped instructions work
Scope Precedence in Instructions and Rules — Full precedence hierarchy