Why the COA String Entered Isn’t Always the One That Gets Used?

Posted on October 13, 2025 by jth6

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.

Net Zero Costs in PPM. What They Are & Why They Matter?

Posted on October 11, 2025 by jth6

Cost Transfers 101 and Net Zero Costs. Summary

A cost transfer is the process of moving a transaction (the financial record) from one funding source (e.g., a specific grant (PPM) or departmental account (COA) to another after the initial transaction has been recorded.
When you initiate a cost transfer, you are creating an offset transaction in the original location (zeroing out the expense) and generating a corresponding, consistent transaction in the destination location, effectively relocating the expense’s financial record.
Before transferring a cost check to see if there’s an equivalent opposite polarity cost (either negative or positive) that has the same Expenditure Type and Item Date. If such a cost exists, it might be a Net Zero transaction and thus not transferrable. See the ‘Identification of Net Zero Costs’ below on how to confirm for sure if it is or is not?

Maintaining Financial Compliance

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

The Three Part Transaction Model

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 :

Original Cost: The initial expense containing the incorrect allocation.

Reversal Cost (The Net Zero Item): The negative entry that mathematically and functionally cancels the Original Cost.
New Cost: The corrected charge applied to the appropriate project elements.

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.

Protecting the Audit Trail

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.