GL/Class Inconsistency
Xenett detects and addresses coding errors, if any. For example, Verizon transactions have always been coded to Telephone. In one of the months, it got coded to the Office Expense account. Xenett helps you find such coding errors and also helps you fix them easily.
Whenever you add a client to Xenett, it configures based on its past history. For example, if all Verizon transactions were always coded to Telephone in the past, it would create a configuration for Verizon vendor, expecting all future Verizon transactions to be coded to the Telephone account. If it gets coded to a different account, Xenett will flag it.
You can then either fix the miscoded transactions or update the configuration if the account that was flagged is okay.
This review point has one more view, which is 'By GL'. In this view, all transactions are grouped by Accounts first and then by vendors.
Let us explain how this view can help you with the example.
Say you're looking at a Travel Account with 50+ transactions. It is not that easy to spot one transaction of a vendor, 'McDonals .'
Now, if you're using this review point and looking at it in By GL view, it is very easy to spot.
![Document image Document image](https://images.archbee.com/gxTQ7SiSJoXVob2bu4KTw/lG1MtNMfxPqUTehudyYXw_image.png?format=webp)
Class Inconsistency works exactly the same way GL Inconsistency works. Just like GL Inconsistency highlights coding issues with GL, it highlights the Class Coding issues in this review point.