The key insight is this: ask yourself whether the instruction is driven by WHO processes the documents (organization scope) or WHERE documents come from (country scope). If your instruction is about internal standardization, business process logic, or downstream system requirements, use organization scope.
If your instruction is about handling geographic conventions, regulatory formats, or locale-specific formatting, use country scope. Many instructions could theoretically fit either scope; this guide helps you make the right choice.
Note on access: Instruction Builds opens on four scope tabs, Trading Party Specific, Organization Specific, Country Specific, and Global. Admins and managers can create and edit builds on the Organization Specific and Trading Party Specific tabs. The Country Specific and Global tabs are admin only. Managers do not see them, and no custom role can be given write access. So if your decision points to country or global scope, an admin has to make that change.
How It Works: The Decision Framework
Core Decision: WHO vs. WHERE
Ask this primary question first: "Is this instruction driven by WHO processes the document (the organization) or WHERE it comes from (the country)?"
Dimension | Organization Scope | Country Scope |
Decision factor | Internal business process or system requirement | Geographic convention or regulatory format |
Example | "Our Finance division requires cost centre validation" | "German invoices use DD/MM/YYYY date format" |
Applies to | All documents processed by that organization | All documents originating from that country |
Overrides | Country and global scopes | Global scope only |
Typical use case | Multi-division, multi-subsidiary, or system-specific logic | Multi-country procurement with locale variations |
Decision Tree
Use this flowchart to determine the correct scope:
START: I need an instruction ├─ Is this instruction driven by WHERE documents come from (geographic location)? │ ├─ YES → Country scope (tax formats, date conventions, currency, language) │ └─ NO → Continue │ ├─ Is this instruction about how a specific organization processes documents internally? │ ├─ YES → Organization scope │ └─ NO → Continue │ ├─ Is this instruction about a specific business relationship or trading party? │ ├─ YES → Trading party scope (not covered here) │ └─ NO → Continue │ └─ Does the instruction apply universally to all documents? ├─ YES → Global scope └─ NO → Reconsider-likely missing a dimension
Decision Criteria and Worked Examples
Example 1: Tax Identification Numbers (Country Scope)
Scenario: Your organization receives invoices from multiple countries. Each country has a different tax ID format and validation requirements. Instruction: "German invoices must have a valid VAT number in the format DE + 9 digits; Spanish invoices must have a valid NIF." Decision: Country scope Reasoning:
The instruction is driven by WHERE documents come from (Germany vs. Spain)
Tax regulations are geographically mandated
An invoice from Germany should follow this instruction regardless of which of your organizations processes it
A different country's invoice should follow its own country instruction Configuration:
Country: Germany
Instruction: Validate VAT format DE + 9 digits
Country: Spain
Instruction: Validate NIF format
Example 2: Cost Centre Validation (Organization Scope)
Scenario: Your Finance organization requires all invoices to reference an approved cost centre. The approved list is: CC-001, CC-002, CC-003. This is an internal business requirement, not a geographic one. Instruction: "All invoices must include a cost centre code from the approved list." Decision: Organization scope Reasoning:
The instruction is driven by WHO processes it (Finance organization)
Cost centre codes are internal to your organization
This instruction applies regardless of the invoice origin country
A different organization might not use cost centres at all or have different codes Configuration:
Organization: Finance
Instruction: Validate cost centre against whitelist [CC-001, CC-002, CC-003]
Example 3: Date Format Handling (Country Scope)
Scenario: Documents from the United States typically use MM/DD/YYYY, while European documents use DD/MM/YYYY. Your system needs to correctly parse these to avoid date errors. Instruction: "US documents use MM/DD/YYYY; EU documents use DD/MM/YYYY." Decision: Country scope (for each region) Reasoning:
The instruction is driven by WHERE documents come from (geographic locale)
Date format conventions are regional/cultural standards
The same organization might receive documents from both regions; each should be handled by the appropriate country instruction
This is not an internal business decision but a formatting convention Configuration:
Country: United States
Instruction: Parse dates as MM/DD/YYYY
Country: Germany (and other EU countries)
Instruction: Parse dates as DD/MM/YYYY
Example 4: Field Mapping for Legacy System Integration (Organization Scope)
Scenario: Your Operations organization uses a legacy ERP system that requires specific field mappings. Documents come from various countries, but they all need to be transformed to match the legacy system's schema before ingestion. Instruction: "Map the field 'Delivery Address' to 'ship_to_location'; map 'Invoice Date' to 'invoice_dt' (legacy field name)." Decision: Organization scope Reasoning:
The instruction is driven by WHO processes it (Operations organization and their ERP system)
Field mapping is about downstream system requirements, not geographic convention
The same document format from different countries should still be mapped the same way
A different organization using a different ERP might need different mappings Configuration:
Organization: Operations
Instruction: Map field names to legacy ERP schema
Example 5: Currency Normalisation (Could Be Either-Analyse Further)
Scenario: All invoices should be normalised to USD for downstream processing. Initial question: "Is this about WHERE documents come from or WHO processes them?" Analysis:
Sub-question: "Are all documents in multiple currencies because they come from different countries?" → Country scope makes sense; you could have an instruction per currency zone
Sub-question: "Or are all documents normalised to USD regardless of origin because our internal system requires it?" → Organization scope makes sense; this is an internal business requirement Decision depends on context: If geography-driven:
Ask an admin to set up country-level currency normalization instructions (e.g., EUR for Europe, GBP for UK, CNY for China), since the Country Specific tab is admin only
Configuration: Country-scoped instructions, one per currency region If business-driven:
Set up organization-level instructions to always normalise to USD
Configuration: Organization scope, with an instruction to normalise all currency values to USD Best practice: If your organization spans multiple countries and each country receives documents in local currency, use country scope. If your internal policy is to standardise all currencies regardless of origin, use organization scope.
Example 6: PO Number Format Standardisation (Organization Scope)
Scenario: Your Procurement organization uses a strict 8-digit format for all PO numbers (29XXXXXX). Vendors sometimes use alternative formats, which need to be standardised before downstream processing. Instruction: "All PO numbers must be standardised to the format 29XXXXXX (8 digits, starting with 29)." Decision: Organization scope Reasoning:
The instruction is driven by WHO processes it (Procurement organization) and their internal standards
This is not a geographic formatting convention but an internal business process requirement
The standardisation applies regardless of the vendor's country of origin
A different organization might use a different PO format Configuration:
Organization: Procurement
Instruction: Standardize PO numbers to 29XXXXXX format
Scope Interaction: What Happens When Both Exist
If you define both an organization instruction and a country instruction for the same extraction scenario, here is what happens:
Scope order applies: the organization instruction is evaluated before the country instruction.
Where the two cover different fields or different aspects of the document: both are applied, in that order.
Where the two genuinely conflict on the same field: the organization instruction wins, because it is the more specific scope.
If no organization instruction matches: the country instruction applies on its own, and anything neither instruction covers falls through to global scope.
Example: Organization Instruction + Country Instruction Coexistence
Scenario:
Organization instruction (Finance): "All invoices must include cost centre code from [CC-001, CC-002, CC-003]"
Country instruction (Germany): "German invoices use DD/MM/YYYY date format" What happens when a German invoice is processed by Finance organization:
System recognises the document is from Germany and processed by Finance
Checks for an organization instruction → Found
Applies the organization instruction (cost centre validation)
THEN applies the country instruction (date format parsing)
Both instructions are applied in sequence, with organization taking precedence if there's any conflict What happens when a French invoice is processed by Finance:
System recognises the document is from France and processed by Finance
Checks for an organization instruction → Found, applies it (cost centre validation)
Looks for a country instruction for France → May not exist
Steps to global scope for any fields not covered by the organization instruction
Common Scenarios and Recommended Approach
Scenario | Recommended Scope(s) | Notes |
Tax ID validation (VAT, GST, FEIN) | Country | Tax formats are regulatory/geographic |
Cost centre codes, internal departments | Organization | Internal standardisation |
Date format parsing (MM/DD vs DD/MM) | Country | Locale convention |
Currency normalisation (to USD) | Depends; see analysis above | Could be either |
PO number standardisation | Organization | Internal business process |
Field label translation (Portuguese to English) | Country | Locale/language convention |
ERP system field mapping | Organization | System integration requirement |
Decimal separator handling (comma vs period) | Country | Locale convention |
Supplier/customer name format standardisation | Organization | Internal data governance |
Invoice line item extraction | Could be either or both | Analyse whether format varies by geography or by org process |
Discount/tax calculation logic | Organization | Business process (though could be regulatory by country) |
Every row recommending country scope is configured on the admin-only Country Specific tab, so raise those with an admin. Organization-scoped rows are open to admins, managers, and any custom role granted write access on the Organization Specific tab.
Avoiding Conflicts and Maintaining Clarity
Best Practices
Document your scope choices: Add comments in your instructions why you chose a particular scope. This helps future maintainers.
Avoid duplicate logic: If you find yourself writing the same instruction in multiple scopes, consolidate it to the appropriate single scope.
Test edge cases: If you have both organization and country instructions, test documents that trigger both to ensure they work together correctly.
Use naming conventions: Name instructions clearly to indicate their scope. For example:
"DE_DateFormat_DD_MM_YYYY" for country scope
"Finance_CostCentreValidation" for organization scope
Review scope usage periodically: As your business evolves, instruction scopes may need adjustment. An instruction that was organization-scoped might later become country-scoped if you expand internationally.
Start with global, then specialize: Begin with global instructions for universal logic, then add organization and country instructions for exceptions. Avoid the inverse (many specific instructions with rare global ones). Global and country builds are set up by an admin, so agree this baseline with your admin before you build out the organization-level exceptions.
Map your configuration: Create a simple spreadsheet showing all instructions, their scopes, and their purpose. This helps you spot redundancies and conflicts.
When to Reconsider Your Scope Choice
You may need to revisit your scope decision if:
An instruction you thought was global is actually used by only one organization → Move to organization scope
An instruction that applied to one country is now needed globally → Move to global scope or expand to multiple countries (both are admin-only changes)
An organization instruction conflicts with a country instruction regularly → Re-evaluate whether the instruction should be organization or country scoped
An instruction becomes too complex to maintain → Simplify and potentially split into multiple, more targeted instructions
Your business structure changes (e.g., acquiring a new subsidiary, entering a new market) → Review instructions to see if new country or organization scopes are needed