Each application that uses unposted item repair (UIR) has two General Ledger (GL) entries:
This allows the GL to remain in balance so that funds are added to and removed from these accounts based on whether the transaction is a credit or debit.
Additionally, there are two GL entries that are used when items cannot post to an account:
Entries made to these accounts require two manual entries:
Examples
When a transaction comes into HORIZON-XE, an opposite offsetting transaction is also created. This is what keeps the GL balanced.
|
Example The customer writes a $20 check to cover a payment. This check enters HORIZON-XE via proof of deposit (POD). As a result, the following occurs in the next BOSS processing:
|
When the transaction cannot post to the customer's account for any one of various reasons, the transaction routes to UIR. As a result, transaction amount cannot post to the customer's account. Instead, the offset transaction amount posts to the unapplied account.
|
Example A $20 check enters HORIZON-XE via POD; however, it cannot post. The following occurs during the next BOSS processing:
|
If the transaction was corrected, it can then post to the account during the next BOSS processing. An opposing transaction amount posts to the unapplied account, and an offsetting transaction amount posts to the customer's account.
|
Example Following the example above, the transaction is corrected so that it can post to the customer's account. As a result, the following occurs in the next BOSS processing:
|
If the transaction cannot be corrected, it is then returned. As a result, the transaction amount is removed from the unapplied account and moved to the return item processing (RIP) account.
|
Example When the check transaction cannot be corrected in UIR, it is returned. As a result, the following occurs in the next BOSS processing:
|