Understanding Account Structures
For: Business Users, Managers, Clients
Purpose: Explain how Account Structures control dimension requirements for different types of accounts
Reading Time: 8 minutes
What is an Account Structure?
An Account Structure is a template that defines which financial dimensions are required, optional, or prohibited for specific ranges of Main Accounts. Think of it as a rule set that tells the system: "For these types of accounts, you must collect these dimensions."
Real-World Analogy
Imagine different types of forms at a hospital:
Emergency Room Form:
- Required: Patient Name, Date of Birth, Emergency Contact
- Optional: Insurance Information
- Not Applicable: Appointment Time (it's an emergency!)
Scheduled Surgery Form:
- Required: Patient Name, Date of Birth, Insurance, Pre-Op Tests, Surgeon Name
- Optional: Special Requests
- Not Applicable: Walk-in Time
Pharmacy Prescription Form:
- Required: Patient Name, Medication, Dosage, Doctor
- Optional: Allergies
- Not Applicable: Surgery Information
Each form has different requirements based on its purpose.
In accounting, Account Structures work the same way:
Balance Sheet Accounts (Assets, Liabilities):
- Required: Business Unit, Cost Center
- Optional: None
- Prohibited: Project, Customer (balance sheet items aren't project-specific)
Revenue Accounts:
- Required: Department, Business Unit, Region
- Optional: Project, Customer (for project-based revenue)
- Prohibited: None
Project Expense Accounts:
- Required: Department, Cost Center, Project
- Optional: Customer (if billable)
- Prohibited: None
Why Do Account Structures Matter?
1. Enforce Data Quality
Without Account Structures:
User enters expense transaction:
Main Account: 5500 - Project Expense
Department: (skipped)
Project: (skipped)
Result: Transaction posts, but you can't track by project!
With Account Structures:
User enters expense transaction:
Main Account: 5500 - Project Expense
Department: (required - system blocks if empty)
Project: (required - system blocks if empty)
Result: Complete data for project tracking
Business Impact: Ensures all transactions have the detail you need for reporting.
2. Simplify Data Entry
Scenario: Cash is never project-specific
Without Account Structures:
User enters cash transaction:
Main Account: 1010 - Cash
System asks for: Department, Project, Customer, Region, Cost Center
User: "Cash doesn't belong to a project!" (confused)
User enters random values to proceed
With Account Structures:
User enters cash transaction:
Main Account: 1010 - Cash
System asks for: Business Unit, Bank Branch only
User: Clear what's needed, fills it in
Business Impact: Faster data entry, fewer errors.
3. Prevent Meaningless Combinations
Some dimension combinations don't make business sense:
Doesn't Make Sense:
- Cash + Customer (cash is general, not customer-specific)
- Accounts Payable + Project (liability is at company level)
- Revenue + Cost Center (revenue isn't tied to production cost centers)
Account Structures prevent these combinations, ensuring data integrity.
4. Support Different Business Processes
Different parts of your business need different detail:
Manufacturing:
- Track by Cost Center, Product Line
- Less emphasis on Projects
Consulting:
- Track by Project, Customer
- Less emphasis on Product Lines
Account Structures let you configure this, so each business process gets the right dimensions.
How Account Structures Work
The Basic Concept
Account Structures define dimension requirements for ranges of Main Accounts.
Example Structure: "Operating Accounts"
Main Account Range: 5000-5999 (Expense Accounts)
Required Dimensions:
1. Department
2. Cost Center
Optional Dimensions:
3. Project
4. Customer
Not Allowed:
- Product Line
- Warehouse
What This Means:
- When you enter an expense (5000-5999), you MUST select Department and Cost Center
- You CAN optionally select Project and Customer (if relevant)
- You CANNOT select Product Line or Warehouse (they don't apply to expenses)
Multiple Account Structures
Most businesses use multiple Account Structures for different types of accounts.
Example: Manufacturing Company
Structure 1: "Balance Sheet Accounts"
Main Account Range: 1000-2999 (Assets and Liabilities)
Required: Business Unit
Optional: Bank Branch (for cash accounts)
Not Allowed: Project, Customer, Product Line
Structure 2: "Revenue Accounts"
Main Account Range: 4000-4999 (Revenue)
Required: Business Unit, Department, Product Line
Optional: Project, Customer, Region
Not Allowed: Cost Center
Structure 3: "Expense Accounts"
Main Account Range: 5000-5999 (Expenses)
Required: Department, Cost Center
Optional: Project, Customer
Not Allowed: Product Line
Why Multiple Structures:
- Different account types need different dimensions
- Keeps data entry focused on relevant information
- Prevents invalid dimension combinations
Dynamic Structure Resolution
Here's the clever part: You don't need to tell the system which Account Structure to use. The system automatically determines it based on the Main Account you enter.
How It Works
Step-by-Step Process:
1. User Selects Main Account
User enters: Main Account 5200 - Rent Expense
2. System Determines Structure
System checks: "Which Account Structure applies to 5200?"
Answer: "Expense Accounts" structure (range 5000-5999)
3. System Shows Required Dimensions
System displays:
Department: (required)
Cost Center: (required)
Project: (optional)
Customer: (optional)
4. User Enters Dimension Values
User completes:
Department: Operations
Cost Center: Warehouse 1
Project: (left blank, not project-specific)
Result: Transaction records with correct dimensions, system ensures requirements met.
The Golden Rule: No Ambiguity
Critical Principle: A single Main Account value can only belong to ONE Account Structure.
Why This Rule Exists
Problem Without the Rule:
Structure A: "Project Accounts"
Main Account Range: 5000-5999
Required: Department, Project
Structure B: "Standard Expenses"
Main Account Range: 5000-5999
Required: Department, Cost Center
User enters: Main Account 5200
Question: Which structure applies?
Answer: AMBIGUOUS! Both structures cover 5200.
This creates confusion - the system doesn't know which dimensions to require.
How the System Prevents This
The system enforces: Main Account ranges in different Account Structures cannot overlap.
Valid Configuration:
Structure A: Balance Sheet
Range: 1000-2999 ✓
Structure B: Revenue
Range: 4000-4999 ✓
Structure C: Expenses
Range: 5000-5999 ✓
No overlap - each Main Account belongs to exactly one structure
Invalid Configuration (System Rejects):
Structure A: Project Expenses
Range: 5000-5999 ✓
Structure B: General Expenses
Range: 5000-5500 ✗ OVERLAP!
System: "Error! Main Accounts 5000-5500 would belong to two structures."
Configuring Account Structures
Step 1: Identify Business Requirements
Ask These Questions:
- What dimensions do we need for analysis?
- Do different account types need different dimensions?
- What's required vs. nice-to-have?
- What combinations don't make sense?
Example Analysis:
For Revenue Accounts, we need:
- Business Unit (required) - which division earned it
- Department (required) - which sales team
- Product Line (required) - what product
- Project (optional) - if project-based
- Customer (optional) - for specific analysis
For Expense Accounts, we need:
- Department (required) - who spent it
- Cost Center (required) - where spent
- Project (optional) - if project-related
- Product Line (not needed) - expenses aren't product-specific
Step 2: Design Structure Layouts
Structure 1: "Balance Sheet Accounts"
Purpose: Assets and Liabilities
Main Account Range: 1000-2999
Position 1 (Required): Main Account (always first)
Position 2 (Required): Business Unit
Position 3 (Optional): Bank Branch
Benefits:
- Simple structure for balance sheet
- Only essential dimensions required
Structure 2: "Revenue Accounts"
Purpose: All Revenue Types
Main Account Range: 4000-4999
Position 1 (Required): Main Account
Position 2 (Required): Business Unit
Position 3 (Required): Department
Position 4 (Required): Product Line
Position 5 (Optional): Project
Position 6 (Optional): Customer
Benefits:
- Complete revenue analysis capability
- Product and department profitability
Structure 3: "Operating Expense Accounts"
Purpose: All Operating Expenses
Main Account Range: 5000-5999
Position 1 (Required): Main Account
Position 2 (Required): Department
Position 3 (Required): Cost Center
Position 4 (Optional): Project
Position 5 (Optional): Customer
Benefits:
- Departmental cost tracking
- Project cost allocation
- Billable expense tracking
Step 3: Define Main Account Ranges
Important Decisions:
Option A: Broad Ranges
Structure: "All Expenses"
Range: 5000-5999 (all expense accounts)
Pros:
- Simple configuration
- One structure for all expenses
Cons:
- All expenses get same dimension requirements
- Less flexibility
Option B: Narrow Ranges
Structure 1: "Project Expenses"
Range: 5500-5599
Structure 2: "General Expenses"
Range: 5000-5499
Pros:
- Different dimensions for different expense types
- More control
Cons:
- More structures to manage
- More complex configuration
Most Businesses: Start with broad ranges (Option A), refine later if needed.
Common Account Structure Patterns
Pattern 1: Simple Structure (Small Business)
One Structure for Everything:
Structure: "Standard Accounts"
Range: All accounts (1000-9999)
Required:
- Main Account
- Department
Optional:
- Cost Center
- Project
Benefits:
- Easy to understand
- Fast to configure
- Suitable for 80% of small businesses
Pattern 2: Three-Structure Pattern (Medium Business)
Most Common Setup:
Structure 1: Balance Sheet
- Range: 1000-3999 (Assets, Liabilities, Equity)
- Required: Business Unit
- Optional: Bank Branch
Structure 2: Revenue
- Range: 4000-4999
- Required: Business Unit, Department, Product Line
- Optional: Project, Customer, Region
Structure 3: Expenses
- Range: 5000-5999
- Required: Department, Cost Center
- Optional: Project, Customer
Benefits:
- Clear separation by financial statement category
- Right level of detail for each category
- Manageable complexity
Pattern 3: Detailed Structure (Large Business)
Five or More Structures:
Structure 1: Current Assets
- Range: 1000-1499
- Required: Business Unit
- Optional: Bank Branch, Warehouse
Structure 2: Fixed Assets
- Range: 1500-1999
- Required: Business Unit, Cost Center, Asset Category
- Optional: Department
Structure 3: Liabilities
- Range: 2000-2999
- Required: Business Unit
- Optional: None
Structure 4: Revenue - Products
- Range: 4000-4499
- Required: Business Unit, Department, Product Line, Region
- Optional: Project, Customer
Structure 5: Revenue - Services
- Range: 4500-4999
- Required: Business Unit, Department, Service Line
- Optional: Project, Customer
Structure 6: Direct Expenses
- Range: 5000-5499
- Required: Department, Cost Center, Product Line
- Optional: Project
Structure 7: Indirect Expenses
- Range: 5500-5999
- Required: Department, Cost Center
- Optional: Project
Benefits:
- Highly specific dimension requirements
- Optimized for each account type
- Maximum reporting flexibility
Drawbacks:
- More complex to configure
- More administrator training needed
Making Configuration Decisions
Question 1: How Many Structures Do We Need?
Start Simple: Most businesses can start with 2-3 structures:
- Balance Sheet accounts
- Revenue accounts
- Expense accounts
Add More If:
- Different business units have very different needs
- Regulatory requirements vary by account type
- Product vs. service revenue need different dimensions
Avoid: Creating too many structures unnecessarily
Question 2: Which Dimensions Should Be Required?
Make Required When:
- Essential for financial reporting
- Needed for regulatory compliance
- Used in budgeting
- Management regularly analyzes by this dimension
Make Optional When:
- Only applies to some transactions in the range
- Nice-to-have for special analysis
- Used occasionally
Example:
Expense Accounts:
Department: Required (always need to know who spent it)
Cost Center: Required (where it was spent)
Project: Optional (only if project-related)
Customer: Optional (only if billable)
Question 3: What Order Should Dimensions Appear?
Best Practice Order:
- Main Account (always first)
- Business Unit (if you have multiple)
- Department (organizational structure)
- Cost Center or Project (operational detail)
- Optional dimensions (Product, Customer, etc.)
Why Order Matters:
- Logical flow for data entry
- Most important dimensions first
- Matches typical user thought process
Account Structure Lifecycle
Stage 1: Draft
Status: Under configuration, not yet active
Activities:
- Define Main Account range
- Configure dimension requirements
- Set dimension order
- Document purpose
Can Be Modified: Yes, freely
Stage 2: Activated
Status: Active and in use
What Happens:
- System validates no overlap with other active structures
- Becomes available for transaction entry
- Users see dimension requirements based on this structure
Can Be Modified: Limited changes only (adding optional dimensions, adjusting ranges if no overlap)
Stage 3: Deactivated
Status: No longer used for new transactions
When to Deactivate:
- Replacing with new structure
- Changing dimension requirements significantly
- Consolidating multiple structures
Important: Historical transactions preserve their original structure
Common Mistakes to Avoid
Mistake 1: Overlapping Main Account Ranges
Problem:
Structure A: Range 5000-5999
Structure B: Range 5500-5599
Main Account 5550 belongs to both structures - CONFLICT!
Solution: Carefully plan ranges to avoid overlap
Mistake 2: Too Many Required Dimensions
Problem:
Structure: Expense Accounts
Required: Department, Cost Center, Project, Customer, Region, Product, Phase
User: "I'm just recording office supplies! Why do I need all this?"
Solution: Only require dimensions that apply to most transactions in the range
Mistake 3: Inconsistent Logic Across Structures
Problem:
Revenue Structure: Department is Position 2
Expense Structure: Department is Position 4
Users get confused - "Why is Department in different places?"
Solution: Use consistent dimension ordering across structures
Mistake 4: Not Planning for Growth
Problem:
Structure: Expenses
Range: 5000-5999
Later: "We need different dimensions for project expenses (5500-5599)"
Issue: Range already assigned to broader structure
Solution: Think ahead about potential sub-categorization
Mistake 5: Changing Active Structures
Problem:
- Structure is active and in use
- Administrator changes required dimensions
- Historical reports break
Solution: Deactivate old structure, create new one instead
Frequently Asked Questions
Can I have multiple Account Structures with the same dimensions?
Yes! Multiple structures can require the same dimensions but apply to different Main Account ranges.
Example:
Structure A: Revenue Accounts (4000-4999)
Required: Department, Product Line
Structure B: Cost of Goods Sold (5000-5099)
Required: Department, Product Line
Same dimensions, different account ranges - perfectly valid
What happens if I enter a Main Account that doesn't match any structure?
System Response: Error message: "No active Account Structure found for Main Account 9999"
Solution:
- Verify Main Account number is correct
- Ensure appropriate Account Structure exists and is active
- Check Account Structure ranges cover your Chart of Accounts
Can I change which dimensions are required after transactions are posted?
For New Transactions: Yes, but requires creating a new structure
For Historical Transactions: No, they keep their original structure
Best Practice: Get dimension requirements right before going live
Do Account Structures affect financial statements?
Directly: No - financial statements are based on Main Accounts
Indirectly: Yes - dimensions enable detailed analysis BEHIND the financial statements
Example:
- Income Statement shows: Total Salaries $500,000
- Dimensional detail shows: Marketing $200K, Sales $150K, IT $100K, Ops $50K
How many Account Structures should we have?
Typical:
- Small Business: 1-2 structures
- Medium Business: 3-5 structures
- Large Enterprise: 5-10 structures
Rule of Thumb: Only create separate structures when dimension requirements are truly different
Can Account Structures be deleted?
Before Use: Yes, if no transactions reference it
After Use: No - deactivate instead
Reason: Historical transactions link to specific structures
Summary
Account Structures are configuration templates that:
- Define which dimensions are required, optional, or prohibited for Main Account ranges
- Enforce data quality by ensuring complete transaction information
- Simplify data entry by showing only relevant dimensions
- Prevent invalid dimension combinations
- Support different business process requirements
Key Concepts:
- One Main Account belongs to exactly ONE Account Structure (Golden Rule)
- System automatically determines structure based on Main Account entered
- Multiple structures support different dimension requirements for different account types
- Dimension order determines data entry flow
- Required vs. Optional vs. Prohibited controls data collection
Best Practices:
- Start with 2-3 broad structures (Balance Sheet, Revenue, Expense)
- Only require dimensions that apply to most transactions in the range
- Use consistent dimension ordering across structures
- Plan ranges carefully to avoid overlaps
- Deactivate old structures instead of deleting them
Key Takeaway: Account Structures are the "traffic rules" for financial dimensions. They ensure every transaction captures the right information, in the right format, without overwhelming users with irrelevant questions. Good Account Structure design makes data entry faster and reporting more powerful.
Related Resources
Business Concepts:
- Understanding Financial Dimensions - The dimensions that Account Structures control
- Understanding Default Dimensions - Automatic dimension assignment
- Understanding Main Accounts - The foundation that structures build upon
User Guides:
- How to Create an Account Structure (administrator setup)
- How to Modify Account Structure Dimensions (configuration changes)
- How to Enter Transactions with Dimensions (user data entry)
For Developers/Architects:
- Account Structure Resolution Service (technical workflow)
- DimensionHierarchy Aggregate (technical implementation)
- Constraint Overlap Detection (technical validation)
This guide is part of the ERP Business Concepts series, designed to help business users understand key financial concepts without technical jargon.