Sub-organizations provide a second level of organizational structure, useful for separating teams, departments, regions, or external partners while maintaining inheritance of shared parent configurations.
Sub-organizations inherit parent settings such as the urgent flag and self-service access, and they are the level at which organization-scoped transformation and rejection rules are created. Each sub-organization can also set an override trading party for the documents uploaded to it.
How It Works
Accessing Sub-Organization Management
Navigate to Settings in the left sidebar
Select Manage Organizations
To view existing sub-organizations, click the arrow on the right of an organization to expand its list of sub-organizations
To add a new sub-organization, click the + icon (the Add Sub-Organization button) on the desired organization
Creating a Sub-Organization
In Manage Organizations, click the + icon (Add Sub-Organization) on the organization you want to add a sub-organization to. The Add new sub organization popup opens.
Complete the fields:
Organization name: A descriptive name for the sub-organization (e.g., "Sales Team", "EMEA Region", "Partner ABC")
Receiver name: The receiver name associated with this sub-organization
Inbox to email attachments: Enter the front part of the sub-organization's email address. The system appends
[tenantname]@docupath.app(for example,trdemo@docupath.app). The front part can contain letters and numbers only, no dashes.External ID (optional): An identifier from an external system (e.g., ERP or CRM) to link with this organization
Configure the optional toggles:
Mark documents from this organization as urgent: When enabled, documents from this sub-organization are flagged as urgent
Enforce organization-only document access (self-service): When enabled, restricts document visibility to this sub-organization
Split documents from this organization: When enabled, a document uploaded to this sub-organization that contains several business documents is separated into one document per part, and each part is processed on its own. The toggle starts out matching the parent organization's setting and can be switched either way.
Click Save (or Cancel to discard)
Important: To have the trading party automatically enriched when a document is uploaded to this sub-organization, create the trading party under Trading Parties and link it using the Override Trading Party option. A maximum of 100 sub-organizations per organization is allowed.
After creation, the sub-organization is ready for:
Assigning trading parties
Creating transformation and rejection rules (organization-scoped rules are created at the sub-organization level)
Assigning users via RBAC
Setting an override trading party
Understanding Inheritance
Parent Settings Inheritance
By default, sub-organizations inherit parent organization settings:
Urgent Flag: If enabled at parent level, the urgent flag is available to users in the sub-organization
Self-Service Access: If enabled at parent level, document visibility is restricted per self-service rules
Document Splitting: If enabled at parent level, documents arriving under the sub-organization are split too
Default Rules: Parent transformation and rejection rules apply to all sub-organizations
Changing the urgent, self-service, or split-documents setting on the parent organization updates every sub-organization that is still following the parent. A sub-organization whose setting was changed on its own keeps its own value and is not affected by later parent changes.
Sub-Organization Customization
Sub-organizations can customize inherited settings:
Transformation and rejection rules scoped as "Organization-specific" are created at the sub-organization level, not at the parent organization. Each sub-organization therefore has its own transformation and rejection rules. (Only instruction builds are scoped at the organization level.)
Disable the urgent flag even if it is enabled at the parent (a sub-organization cannot enable it if the parent has it disabled)
Disable self-service access even if it is enabled at the parent (a sub-organization cannot enable it if the parent has it disabled)
Turn document splitting on or off independently of the parent, in either direction
Be assigned different trading parties
Scope Precedence
In the scope precedence hierarchy:
Trading party rules have the highest precedence
Organization-scoped rules apply next; for transformations and rejections, these are created and applied at the sub-organization level
Global rules have the lowest precedence
Trading Parties and Sub-Organizations
Default Trading Party Assignment
When you create a trading party, you assign it by selecting one or more organizations - which automatically includes all of their sub-organizations - or by selecting one or more specific sub-organizations. This determines which sub-organizations can access and process documents involving that trading party. No additional configuration is required for inherited access.
Override Trading Party
An override trading party replaces the primary party detected on documents uploaded to a sub-organization. The primary party is the buyer on an invoice, Party A on a contract, and so on. Whether the detected party is already configured as a trading party on the tenant or is unverified and derived from the document, it is replaced entirely by the override trading party, and its extracted values are replaced by the override trading party's values.
To set an override trading party:
In Manage Organizations, click the arrow on the right of the organization to expand its list of sub-organizations
On the desired sub-organization, click the home icon (the Override Trading Party button)
Select a trading party from the list in the popup
The override now applies to every document uploaded to that sub-organization
To have the override trading party automatically enriched on upload, the trading party must first be created under Trading Parties.
Deleting Sub-Organizations
Sub-organizations can be soft-deleted (archived):
In Manage Organizations, click the arrow on the right of the organization to expand its sub-organizations
On the row of the sub-organization you want to remove, click the Delete button (trash icon) on the right
The sub-organization is marked as inactive; documents remain accessible
Deleted sub-organizations cannot be re-enabled; consider an archiving strategy
Sub-organizations will be fully removed from the tenant once their trading parties, instructions and rules are also deleted.
Use Cases
Departmental Separation
Create sub-organizations for Sales, Finance, and Operations teams:
Sales sub-org: assigned only customer trading parties
Finance sub-org: assigned all trading parties; has specific invoice validation rules
Operations sub-org: assigned only supplier trading parties
Regional Subdivision
Divide a global parent organization by geographic region:
North America sub-org: inherits parent settings; has region-specific rejection rules (e.g., USD currency, US tax IDs)
EMEA sub-org: region-specific rules for EUR currency and GDPR compliance
APAC sub-org: disable the urgent flag if not needed; region-specific rules for local formats
Partner Management
Create sub-organizations for external partners or subsidiaries:
Partner ABC sub-org: assigned the trading parties within the ABC relationship; an override trading party can enrich uploaded documents with the ABC party
Subsidiary XYZ sub-org: inherits parent configurations; has its own email and self-service access
Each partner has isolated document processing and reporting
Inherited Urgent Flag Example
Parent organization has the urgent flag enabled:
All sub-organizations inherit this setting
Users in any sub-organization can mark documents as urgent
Urgent documents appear in high-priority queues across all sub-organizations
To disable the urgent flag for a specific sub-organization:
Open the sub-organization for editing
Turn off Mark documents from this organization as urgent
Click Save
Email and Notifications
Each sub-organization has its own email address:
You enter the front part of the address (letters and numbers only, no dashes); the system appends
[tenantname]@docupath.appUsed for rejection notifications and workflow approvals targeting the sub-organization
Should be monitored by the sub-organization's responsible team or distribution list
The email address is set at creation and cannot be edited afterward
Viewing and Editing Sub-Organizations
Navigate to Settings > Manage Organizations
Click the arrow on the right of the parent organization to expand its sub-organizations
Open the sub-organization you want to view or edit
You can edit:
Organization name
Receiver name
External ID
The urgent, self-service, and split-documents toggles
Trading party overrides
Rules (transformation and rejection)
The email address cannot be edited
Make changes and click Save
Supported Configurations and Options
Feature | Supported | Notes |
Sub-organizations per parent | Yes | Up to 100 per parent organization |
Sub-organization naming | Yes | Descriptive names (255 char limit) |
Yes | Front part entered at creation (letters and numbers only); tenant suffix appended; not editable afterward | |
Parent urgent flag inheritance | Yes | Default on; can disable |
Parent self-service inheritance | Yes | Default on; can disable |
Parent document-splitting inheritance | Yes | Starts out matching the parent; can be set either way per sub-organization |
Trading party override | Yes | Replaces the primary party detected on the sub-organization's documents |
Sub-organization-level rules | Yes | Organization-scoped transformation and rejection rules are created at the sub-organization level |
User assignment via RBAC | Yes | Users can be mapped to specific sub-organizations |
Self-service per sub-org | Yes | Can be configured differently than parent |
Urgent flag per sub-org | Yes | Inheritance or override per sub-organization |
Sub-organization nesting | No | Only two-level hierarchy (parent + sub) |
Deletion/archiving | Yes | Soft delete; documents remain accessible |
Email notifications | Yes | Sub-organization email used for notification |
Other Technical Specifications
Parameter | Specification |
Hierarchy depth | Two levels only (parent organization + sub-organizations) |
Sub-organizations per parent | Maximum 100 |
Sub-organization naming | Free text; 255 character limit |
Email field | Front part entered at creation (letters and numbers only); tenant suffix |
Inheritance model | Parent settings inherited by default; can be disabled |
Trading party override | Replaces the primary party detected on documents uploaded to the sub-organization |
Rule scope precedence | Organization-scoped transformation and rejection rules are created and applied at the sub-organization level |
Urgent flag | Boolean; inheritance optional |
Self-service access | Boolean; inheritance optional |
Deletion | Soft delete (archive); documents remain in system |
User mapping | Users can be assigned to sub-organizations via RBAC |
Max rules per scope | 100 rule groups, 500 rules per group |
Notes and Limitations
Parent Organization: Sub-orgs inherit parent settings such as the urgent flag and self-service access
Trading Party Management: Trading parties are assigned by selecting organizations (including all their sub-organizations) or specific sub-organizations
Transformation Rules: Organization-scoped transformation rules are created at the sub-organization level
Rejection Rules: Organization-scoped rejection rules are created at the sub-organization level
Override Trading Party: Replaces the primary party detected on documents uploaded to the sub-organization with the configured trading party
Access Control: Users mapped to sub-organizations; combined with self-service access for visibility control
Activity Logs: All sub-organization changes logged; document processing shows which sub-org processed
Email Notifications: Sub-organization email used for rejection and workflow notifications
Scope Precedence: Trading party rules take precedence, then organization-scoped rules (at the sub-organization level), then global rules
Limitation | Workaround |
Two-level hierarchy only | No nested sub-sub-organizations; plan structure with parent + single child level |
No sub-organization deletion reversal | Soft deletion is permanent; consider archiving strategy and naming conventions |
Email not editable | The email address is fixed at creation; choose the front part carefully before saving |
Rule location may be unclear | Sub-org users may not realize that organization-scoped transformation and rejection rules live at the sub-organization level; document this clearly |
Override trading party scope | When an override trading party is set, every document uploaded to that sub-organization has its primary party replaced; ensure this is intended before enabling |
Email uniqueness | Sub-organization emails must be unique within tenant; ensure naming prevents collisions |
Cross-sub-org relationships | Documents spanning multiple sub-organizations follow parent organization scoping; ensure routing is correct |