Source system transactions come in different shapes and sizes on Accounting Hub implementations – from single line transactions to huge transactions having thousands of lines each. Transaction size is a common concern in pass-through implementations when source system data is in the form of pre-accounted debit and credit balances. Volume (rather than size) is typically a concern in event based implementations when source systems are passing raw transaction data.
This blog focuses on transaction size and what you – as an implementer – can do to optimize processing of very large transactions by the accounting engine.
Using Subledger System Options you can tune the number of parallel workers and the processing unit size for Create Accounting and Post Subledger Journal Entries (transfer to GL). These settings largely affect performance of accounting processes, especially in high volume scenarios.
But processing unit size refers to the number of transaction headers picked by a worker for processing in a single commit unit. The same worker is always processing all transaction lines of a transaction header. Which is why making very large transactions perform well is that hard. A single header with hundreds of thousands of lines performs much worse than multiple headers with a thousand lines each. This is especially important in case of accounting errors (e.g. an inactive account value).
Our recommendation
Consider breaking up the source data into multiple transaction headers with fewer lines each. This way, the load will be parallelized across multiple workers.
Natural split criteria
Start by exploring natural criteria to split the feed into multiple balanced portions. Looks for dimensions like ledger, legal entity, branch, balancing segment value, currency, etc.
For instance, in multiple legal entities per ledger scenario, you could break up the full trial balance into individual legal entity trial balances.
If the number of lines per header is still not manageable (i.e. more than a couple of thousand), consider breaking it up further. Here is an example of how you could use explicit balancing rules to do that.
Explicit balancing rules
In our example, the Deposits source system provides balanced account activity to Accounting Hub. Daily transaction feeds come in the form of a single transaction header with multiple lines – one for each account that had activity that day.
To illustrate the concept, we’ll take a small sample transaction with seven lines only.
This transaction is effectively a pass-through journal represents balanced account activity and can be directly passed through Accounting Hub to create a balanced journal entry.
You can split the source transaction into two separate transactions with fewer transaction lines each:
These two transactions are not balanced though. The first transaction is unbalanced with debits exceeding credits by 370. The second transaction has credits exceeding debits by the same amount.
To balance the resulting accounting entries, you need explicit balancing rules added to your Subledger Accounting setup.
Create a couple of journal line rules – a debit summarizing all credits and a credit summarizing all debits. In the subledger journal entry rule set, assign the same clearing account to both journal line rules.
This way, the resulting accounting entries for each transaction will be balanced against the clearing account.
Check the balance of the clearing account to ensure it balances as expected.
Automated option
Starting 25A, you can choose to have large transactions split and balanced automatically. Check out Automatically Prepare Large Volume Transactions for Accounting for details on how the feature works and steps to enable.
Conclusion
For a better processing performance of the accounting engine keep transactions at a reasonable size. Ideally, you can split your transaction data into smaller balanced portions by some natural criteria. If you need to split the data further into even smaller portions, just add subledger accounting rules to explicitly balance the accounting or use the automated option.