Purchase Order Perspectives
As a submitter of a purchase request, you may have found yourself entering two different pieces of accounting information. You diligently entered the Account Number (COA) you thought was correct—say, one for General Operations (Fund Type 101). But because the expense was project-related (a faculty fund), you also linked it to a specific Project. You may have wondered, “Which one does the system actually use?” The good news is, by including the Project information, you’ve done everything correctly, even if the COA you entered was technically wrong.
As an approver viewing the transaction in the Purchasing and Payments dashboard, you may notice this confusing dual entry. Perhaps you see both the COA string (Fund Type 101) and the Project information (Faculty Fund – which you know to actually be Fund Type 109) listed…an apparent contradiction. This can lead to the question: Did the system make a mistake? Is there a glitch that will mess up the final reports? Absolutely not! This is a common situation, but it’s actually a sign that your finance system is working exactly as it should, following a strict set of data hierarchy rules.
Data Hierarchy
1. The Requisition
When you create a requisition, think of it as if you are making a request to where the ‘address’ for the cost will be sent to?
- You can enter two kinds of addresses: You might put in both the COA string (ZIP code) and the Project (street address) information.
- The Dashboard View: When you look at the transaction in the Purchasing and Payments dashboard, you are simply seeing your original input. The system is just showing you what the requester submitted, even if they put in two conflicting addresses.
- The Golden Rule: At this stage, the system doesn’t try to correct you. It just accepts the dual input and focuses on getting the purchase approved.
2. The Data Hierarchy
Once the purchase is approved and the bill is ready to be paid, the system has to decide which “address” to use for the final accounting record. This is where the hierarchy kicks in.
In iO, the Project information always wins. Why? Because Project accounting is the most specific (street address is more specific than ZIP code) and has the strictest rules.
| Your Input | iO’s Decision | Why? |
| Project Information is Present | IGNORE the Account String (COA) for final accounting. | The specific Project Rules are more important than the general COA string rules. The cost must follow the Project. |
| Project Information is Missing | USE the Account String (COA). | There are no special rules, so it defaults to the general address. |
The Core Principle: If you link a cost to a Project, that Project acts like a powerful magnet that pulls the cost into its specific set of accounts, completely ignoring the weaker COA string you originally typed.
Finding the Truth: Where the Money Really Goes
The whole purpose of this system is financial integrity. We don’t want someone accidentally charging a restricted grant expense to the general operating fund just because they typed the wrong account number on a request form.
The system uses a set of automatic rules, called Sub-Ledger Accounting (SLA), to determine the correct and final account number based on the Project’s setup.
Your Source of Truth
To stop guessing and see the final, audited truth, do not rely on the COA you see in the Purchasing and Payments dashboard. That dashboard only shows the initial input.
Instead, go directly to the Project Costs Module (which is part of the Project/Grant system).
- Find your transaction within the Project Costs Module.
- Look for an option called “View Accounting.”
When you click this, you will see the final, derived account number. This is the real account (Fund 109 in our example) that received the charge—proof that the system correctly followed the specific Project rules and ignored the conflicting number you saw on the requisition dashboard.