For those of you that were unable to attend today’s zoom session on this topic, the recording of the introduction to the new methodology for internal cost and revenue accounting for service centers and auxiliaries at Rice is available via this Rice box folder link.
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.
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?
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.
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.
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).
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.
Administrative staff engaged in project financial management occasionally need to adjust and transfer project costs. However, a specific transaction type—the Net Zero Cost—is systematically restricted from further transfers or manipulation.
This restriction is not a system error; it is a critical automated safeguard. The principle of the Net Zero Cost ensures that the Project Portfolio Management (PPM) subledger maintains absolute synchronization and balance with the General Ledger (GL). Identifying the Net Zero Item flag is essential for administrative efficiency, as attempting to adjust these items will result in immediate system rejection, confirming that the transaction’s accounting role has already been fulfilled as a cancellation record
A Net Zero Cost transaction is a specialized, negative accounting entry generated automatically by the system to execute the formal reversal of a prior expenditure item. Its function is cancellation; it does not represent an actual, allocable expense.
Cost corrections in PPM always utilize a three-part transaction model :
The Net Zero Item attribute is the field that explicitly identifies the Reversal Cost as True. This confirms that the transaction is the necessary offset, designed to create a zero balance for the pair.
Net Zero Costs cannot be transferred because they are defined as reversed expenditure items and are explicitly disallowed from further adjustment.
The Net Zero transaction’s sole purpose is cancellation. If a transfer were permitted on the Net Zero transaction, the original charge would become effectively uncanceled at its source. The transfer is rejected to maintain the integrity of the audit sequence, as the Net Zero entry is the immutable record linking the cancellation back to the original source charge. Disruption of this linkage results in the system issuing a mandatory rejection message stating that adjustments are not allowed on a reversed expenditure item.
Identification of Net Zero Costs
Right now, there’s only one place in iO where you can confirm the status of a transaction relative to it being part of a net zero pair.
Go to Grants Management/Awards
Click on the Page icon on the right of the page
Search for the award that contains the project that contains the cost. Click on the drop down next to the project that contains the cost. Select Manage Project Costs
If this is the first time that you’ve ever looked at this Project Costs view, you may need to ensure that the net zero column is selected.
When examining the row with the cost that you are considering transferring, you can see the net zero column that indicates if it is or isn’t a net zero transaction.
When you see an x, it is not a net zero transaction and is transferrable. If you see a tick mark, it is a net zero transaction and it is not transferrable.
The Research and Cost Accounting (RCA) office is happy to announce an upcoming upgrade to how we manage personnel roles in sponsored awards within iO. If you’ve ever wondered why someone who left three years ago still appears to have access to your grant data, you’ll be happy to hear that we’re giving everyone a structured way to clean up!
When an award is first set up, we determine the key roles: the PI, Co-PI(s), Project Manager, and Award Participant(s) are all correctly added to the iO award.
But then things change. People move, responsibilities shift, and suddenly, you need to add someone or, more importantly, remove someone. Currently, these adjustments are handled one by one via individual iO tickets (Category = Access Permissions).
This process made good award hygiene an absolute chore:
The result? We’ve sometimes been operating with a slight (or not-so-slight) disconnect between the data in iO and reality, leaving us asking, “Who exactly is supposed to be seeing this data?”
To finally make data management manageable, RCA is implementing a new process that takes advantage of a superb FIS-developed tool that enables organizational-level batch adjustments for award personnel. Consider it your mandatory, but very helpful, data “spring cleaning” session.
This new process is scheduled to be rolled out during Calendar Year 2025, with a likely implementation in early November. We’ll share more detailed instructions and dates as we get closer.
If you have any questions, concerns, or suggestions about this upcoming process, please let us know! Email RCA directly at jth6@rice.edu.
RCA are rolling out important, mandatory updates to how service centers and auxiliary units charge costs to sponsored projects and faculty funds, and how the corresponding revenue is recorded. These changes are the result of work by the Service Center Task Force and are designed to prevent transaction errors, eliminate duplicate entries, and significantly simplify your monthly and period-end reconciliation processes.
Please read this communication carefully, as these new protocols are effective immediately.
The biggest change involves separating transactions into two distinct methods based on where the cost is being charged (the destination).
The ADFdi method ensures that the cost and its corresponding revenue are successfully linked and posted together, which is the key to accurate and easy reconciliation.
To ensure a smooth transition to the new ADFdi process (Scenario B), we’ve incorporated a powerful pre-submission validation tool directly into the template. Before you attempt to post a transaction, the tool will perform critical checks, including:
This validation will save your teams significant time by catching common errors before a failed posting attempt, allowing you to quickly communicate accurate information to your customers.
We understand these are significant procedural changes.
An introductory training session will take place via zoom on October 15th at 11am.
[EDIT – see video recording of this session]
This change is going to primarily impact Service Centers (SEA, Chem Stockroom etc.) and Auxiliaries (Housing & Dining, Post Office etc.) but attendance is not limited. All are welcome.
Following this zoom training, there will also be an in person training session in Moody 205 (11.30-13.00) where we will do a walk through of the new ADFdi template, submission process, and validation tool. Details on this training will be added to this post, and communicated via the research-l listserve as soon as they are known.
—
If you have an urgent need to use the new ADFdi template to generate a cost/revenue transaction in the next two weeks, please reach out to James Hayward (jth6) in the Controller’s Office for assistance. Otherwise, please save your questions for the scheduled training session.
Thank you for your cooperation as we implement these necessary controls for more accurate and efficient accounting at Rice.