Posting Profiles
GL account mapping system that powers automatic double-entry bookkeeping for all transaction types
Posting Profiles
Posting profiles define which general ledger (GL) accounts to debit and credit when posting a transaction. They are the backbone of automatic double-entry bookkeeping in AI-Native ERP, ensuring that every transaction -- from customer invoices to bank fees -- generates correct journal entries without manual account selection.
Why Posting Profiles Matter#
Without posting profiles:
- Every transaction requires manual GL account selection
- Automated agents cannot post bank transactions
- Inconsistent account usage across similar transactions
- Higher risk of posting errors
With posting profiles:
- Customer invoices automatically debit Accounts Receivable and credit Revenue
- Bank fees automatically debit Bank Charges and credit the bank's cash account
- AI agents process bank statement lines end-to-end without human intervention
- Consistent GL treatment across all transactions of the same type
How Posting Profiles Work#
The system uses a two-level mapping:
Transaction Type (e.g., BANK_FEE)
--> Transaction Type Mapping (links type to profile, with priority)
--> Posting Profile (e.g., "Operating Expenses")
--> Debit Account: 6200 (Administrative Expenses)
--> Credit Account: 1000 (Cash and Cash Equivalents)
When a transaction is created, the system:
- Looks up the transaction type (e.g., AR_INVOICE, AP_PAYMENT, BANK_FEE)
- Finds the active posting profile mapped to that type for the relevant entity
- Uses the profile's debit and credit accounts for the journal entry
If multiple profiles are mapped to the same transaction type, the one with the highest priority (lowest priority number) is used.
Profile Lifecycle#
Posting profiles go through three stages:
1. Seeding (During Onboarding)#
When a new legal entity is set up, the system automatically creates a complete set of posting profiles from a template. Templates are available for different accounting standards:
| Template | Profiles | Transaction Mappings |
|---|---|---|
| IFRS | 31 | 32 |
| US GAAP | 31 | 32 |
| Simple | 25 | ~26 |
This means every new entity is immediately ready to process transactions with correct GL postings.
2. Runtime (During Transaction Processing)#
When transactions are posted -- whether manually or by automated agents -- the system looks up the appropriate posting profile and uses its accounts for the journal entry. Profiles are cached during processing for performance.
3. Management (Ongoing Configuration)#
Profiles can be created, updated, or deactivated as your chart of accounts evolves or business needs change.
Transaction Type Mappings#
Every transaction type is linked to a posting profile. Here is the complete mapping for the IFRS template:
Customer Transactions#
| Transaction Type | Profile | Debit Account | Credit Account |
|---|---|---|---|
| AR Invoice | Customer Receivables | Trade Debtors (1100) | Revenue (4000) |
| AR Credit Memo | Customer Receivables | Trade Debtors (1100) | Revenue (4000) |
| AR Debit Memo | Customer Receivables | Trade Debtors (1100) | Revenue (4000) |
| Recurring Invoice | Customer Receivables | Trade Debtors (1100) | Revenue (4000) |
| AR Payment | Customer Payment Receipt | Cash (1000) | Trade Debtors (1100) |
Vendor Transactions#
| Transaction Type | Profile | Debit Account | Credit Account |
|---|---|---|---|
| AP Invoice | Vendor Payables | Admin Expenses (6200) | Trade Creditors (2000) |
| AP Credit Memo | Vendor Payables | Admin Expenses (6200) | Trade Creditors (2000) |
| AP Debit Memo | Vendor Payables | Admin Expenses (6200) | Trade Creditors (2000) |
| AP Payment | Vendor Payment | Trade Creditors (2000) | Cash (1000) |
Banking Transactions#
| Transaction Type | Profile | Debit Account | Credit Account |
|---|---|---|---|
| Bank Deposit | Bank Deposit | Cash (1000) | Varies |
| Bank Withdrawal | Bank Withdrawal | Varies | Cash (1000) |
| Bank Transfer | Bank Transfer | Cash (1000) | Cash (1000) |
| Bank Fee | Operating Expenses | Admin Expenses (6200) | Cash (1000) |
| Bank Interest | Service Revenue | Trade Debtors (1100) | Service Revenue (4100) |
Inventory Transactions#
| Transaction Type | Profile | Debit Account | Credit Account |
|---|---|---|---|
| Inventory Receipt | Inventory Receipt | Inventories (1300) | Trade Creditors (2000) |
| Inventory Shipment | Inventory Shipment | Cost of Sales (5000) | Inventories (1300) |
| Inventory Adjustment | Inventory Adjustment | Stock Losses (5300) | Inventories (1300) |
Other Transactions#
| Transaction Type | Profile | Debit Account | Credit Account |
|---|---|---|---|
| Journal Entry | Manual Journal Entry | Suspense (8000) | Suspense (8000) |
| Fixed Asset Acquisition | Fixed Asset | PPE (1600) | Cash (1000) |
| Depreciation | Depreciation Expense | Depreciation (6400) | Accumulated Depreciation (1620) |
| FX Gain | FX Gain/Loss | FX Loss (7200) | FX Gain (4800) |
| FX Loss | FX Gain/Loss | FX Loss (7200) | FX Gain (4800) |
| Tax Payment | Tax Payment | VAT Payable (2300) | Cash (1000) |
| Intercompany Charge | Intercompany | Clearing (8050) | Clearing (8050) |
Bank Transaction Integration#
Bank transactions use a hybrid approach for GL account resolution:
- Bank side -- The bank account's own GL account (configured per physical bank account)
- Counterpart side -- The posting profile for the transaction type
Example: Bank fee of $5.00
- Bank side (credit): The bank account's GL account (e.g., 1000 - Cash LHV EUR)
- Counterpart (debit): Posting profile for BANK_FEE (e.g., 6200 - Administrative Expenses)
- Result: DR 6200 / CR 1000
This hybrid approach allows the same posting profile to work with any bank account, since the bank-side account is always determined by the bank account configuration.
Automatic Profile Creation#
When the bank transaction processing agent encounters a transaction type with no posting profile, it:
- Skips the transaction line (no fallback to avoid incorrect GL entries)
- Requests the configuration agent to create the missing profile
- The configuration agent looks up appropriate GL accounts and creates the profile
- The bank processor retries the skipped lines with the new profile
This agent-to-agent collaboration means missing profiles are resolved automatically without human intervention in most cases.
Managing Posting Profiles#
Creating a Profile#
When creating a posting profile, you specify:
- Profile name -- Human-readable description (e.g., "Bank Fees")
- Profile type -- Category (e.g., "bank_fee", "customer", "vendor")
- Debit account -- GL account number to debit
- Credit account -- GL account number to credit
- Transaction type -- Optionally link to a transaction type during creation
- Is default -- Whether this is the default profile for its type
Setting a profile as default automatically unsets any previous default for the same profile type and entity.
Updating a Profile#
You can update any combination of fields on an existing profile:
- Change the profile name or type
- Reassign debit or credit accounts
- Update the default status
- Add or change the linked transaction type
Deactivating a Profile#
Deactivation is a soft delete that:
- Marks the profile as inactive
- Deactivates all linked transaction type mappings
- Preserves the record for audit history
NULL Accounts#
Some profiles intentionally have a NULL debit or credit account. This is used for bank transactions where one side of the entry is dynamic:
- Bank Deposit -- Credit account is NULL because the deposit source varies
- Bank Withdrawal -- Debit account is NULL because the expense category varies
In these cases, the NULL side is resolved at transaction time from the bank account's GL configuration or the transaction categorization.
Default Profiles#
Each profile type can have one default profile per entity. The default is used when:
- A transaction type is mapped to a profile type
- Multiple profiles exist for the same type
- No specific override is in place
When you set a new default, the previous default for that type and entity is automatically unset.
Troubleshooting#
"No posting profile found for transaction type X"#
This means the transaction type is not mapped to an active posting profile for the entity.
Resolution: Create a posting profile with the appropriate GL accounts and link it to the transaction type. The system will auto-create the mapping if you specify the transaction type code during profile creation.
Wrong GL Accounts on Transactions#
If transactions are posting to incorrect accounts, you can:
- Update the existing profile to correct the accounts (future transactions use the new accounts)
- Create a new default profile (the old one remains but loses default status)
Note: Correcting a profile does not retroactively fix past transactions. Use journal entries to correct historical postings.
Profile Types Reference#
The 31 profile types in the IFRS template cover all standard business transactions:
| Category | Profile Types |
|---|---|
| Customer | customer, customer_payment |
| Vendor | vendor, vendor_payment |
| Banking | bank_deposit, bank_withdrawal, bank_transfer, expense, revenue |
| Inventory | inventory_receipt, inventory_shipment, inventory_adjustment |
| Fixed Assets | fixed_asset, depreciation |
| Payroll | payroll_salary, payroll_tax_employer, payroll_tax_employee |
| Tax | vat_output, vat_input, tax_payment, tax_adjustment |
| FX | fx_gain_loss |
| Revenue Management | usage_accrual, wallet_topup |
| Journal | journal_entry, reclassification, opening_balance, closing_entry |
| Allocation | cost_allocation, revenue_allocation |
| Intercompany | intercompany |
Each profile type can have multiple profiles per entity, but only one can be the default at a time.
Subscribe to new posts
Get notified when we publish new insights on AI-native finance.