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 standardisation, 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.
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:
Set up country-level currency normalisation instructions (e.g., EUR for Europe, GBP for UK, CNY for China)
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: Standardise 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's what happens:
Scope precedence applies: Organization scope is checked before country scope
If the organization instruction matches the document: It is applied; the country instruction is NOT consulted
If the organization instruction doesn't match: System steps down to country scope
If both match: The organization instruction wins (higher precedence)
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) |
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 specialise: 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).
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
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