The intent of this document is provide the reader with a fundamental understanding of Oracle’s Cross Validation Rules, enriched with lessons learned from actual implementations. Matt Makowsky is an Oracle Financial Applications Consultant with 17 years experience and a Senior Solutions Architect with Perficient. Feel free to ask him any questions in the comments section below the blog.
Cross Validation Rules, when implemented with Dynamic Insertion are a key control that, when implemented properly, can ensure the integrity of financial reports by preventing journal line postings against what would otherwise be considered invalid code combinations.
A code combination is a “string” of combined accounting segments that effectively tag a gl transaction across many dimensions of your business, for example: Legal Entity, Account, Cost Center, Product Line, Location. When values from these segments are combined in a journal entry line, a “code combination” is created, and that financial transaction can be reported independently within each segment.
Dynamic Insertion, when enabled, allows users to create code combinations “on the fly”, which is effective for efficiency, but by itself can create invalid data if a user creates a financial transaction with two or more segment values that don’t make sense. For example, a product line of “leather chairs” may not exist in the cost center of “IT Group”. One or the other may be correct, but obviously one or the other is incorrect, and therefore financial reporting will not reflect reality. The IT Group may be being charged for expenses that belong to manufacturing, or the product line of leather chairs may be charged with costs for IT salaries.
Cross Validation Rules can be used to control how dynamic insertion behaves when subjected to manual user inputs from throughout the enterprise.
Cross Validation Rules are written in ranges, across segments, specifically defining ranges of values across segments that cannot post together. With a well defined chart of accounts, and meaningful ranges within segments, cross validation rules can be very easy to write and maintain. If you are having difficulty writing effective rules, or they are too confusing, this could be a sign that your chart of accounts is not optimally defined, and should be revisited.
1 – Keep the rules high level and simple. If they are too detailed, your chart of accounts may not be optimally defined. For example, it should be relatively easy to write a simple “P&L/Cost Center” rule, which would state that all P&L accounts must be assigned a cost center other than “00000”. If your accounts are created properly, then all your P&L accounts should be ranged between 400000 and 999999 (for example) without any gaps for other types of accounts.
2 – Focus on areas that are “heavy” with manual journal entries and prone to user error. If certain sets of accounts are posted automatically by subledger systems and should not have manual journals, these types of accounts can be ignored, and addressed later if you find people begin posting manually to these accounts.
3 – When writing a rule, consider only two segments at a time. More than two will make the rule confusing. It’s easier to make multiple rules across two segments rather than trying to create rules across 3 segments. These are “AND” conditions. So if attempting to use 3 segments, all 3 must be true at the same time in order for the rule to be effective.
4 – Group Rules logically. Oracle provides for many different rules, each which can have many lines associated to the rule. For example, you may have a “Product Line/Legal Entity” rule whereby certain legal entities cannot be combined with certain product lines. Do not try to combine this rule with a “Cost Center/Product Line” rule which would indicate a product line may be invalid for a give cost center. Group these separately, so the rules are easy to maintain and the error messaging is clear to the end user as to which segment should be corrected. Combining the concepts will make this unclear and confusing.
5 – Every new rule must have a “universal include” row, and then followed by “excludes”. Avoid using “Include” rules in the details. Work on the principle of management by exception. Make a universal include rule, and then enter excludes as exceptions. A universal include will have a range of 0000’s to zzzz’s for each segment. Exclude rows would then exclude low to high ranges across 2 segments. There is no need to fill in 000’s to zzz’ across each segment when writing your exclude rows. Not doing so will make it easier to read the rules.
6 – Make error messaging clear and concise so that users understand the nature of the errors.
7 – Run the cross validations rule violation report after keying in your cross validation rules (in environments that have established code combinations). This report will tell you all existing code combinations that would be invalid based on your new rules. You may determine that the rule itself is invalid and needs correction.
8 – Monitor and adjust rules as needed. Reclassify invalid transactions, then disable bad code combinations. Write new rules to prevent similar transactions from occurring in the future.
Note: Once a code combination is created, a cross validation rule will no longer prevent it from being used in the future. The code combination itself must be disabled after the amounts are reclassified.
Lastly, the definition of and maintenance of cross validation rules should be limited to very few users. Always have a back up person in case someone is on vacation, especially at month end.