Project Billing "write-off" options

Question

I'm attempting to determine the best method of "writing off" transactions on direct projects that have been reported as billable, accrued revenue but will never be billed. Please consider the following narrative as an example:
A consultant (consultant x) charges April time and expense to project 10001 in a billable capacity (charged transactions to a billable task). The transactions are cost distributed, revenue distributed and an invoice is subsequently produced. All cost and revenue transactions are produced, interfaced and ultimately posted to the general ledger in April. The month of April is closed in PA and the invoices for the April billing cycle are produced. Project 10001's draft invoice includes those charges reported by consultant x and is distributed to the project manager for approval. The project manager reviews the invoice review and determines that consultant x's transactions will never be billed and instructs the accounting group to write off the transactions.
Challenge: we need a way to "write-off" (reduce revenue and change billing status) transactions that will allow for consistent reporting and measurement. Specifically, we need to be able to determine all write-off's (revenue/billing reductions) in a given period that relate to original transactions from an earlier or different period. In short, we want to establish a policy and procedure for consistently processing and reporting these types of conditions.
Proposed Options:
1) use the "special" non-billable adjustment option from either expenditure inquiry or invoice review to change the billing status from billable to non-billable.
Pros:
a) transactions will remain on the project in the capacity they were reported by the employee
b) an adjustment record will be created in the PA_Expend_Item_adj_Activities table which will include the adjustment activity code (i.e. Billable Reclass, Non-billable reclass, billing hold, billing hold release, etc.)
c) history of who created original transactions and adjustments is available (full audit trail)
d) a reversing revenue entry will be created in the PA_Cust_Rev_Dist_Lines_all table which will allow us to track the dates (gl period) of the revenue adjustment and compare it to the original transaction dates.
Cons:
a) to the average users the transaction on a billable task flagged as non-billable with no corresponding revenue may look unusual because there is no description explaining why the adjustment existed. the only way to determine that revenue existed and was subsequently reversed is to look at item details- revenue details.
b)The revenue write-off will be charged to the same accounts (revenue and inventory) that the original transaction was booked to but in reverse. we don't have the ability to deflect the "write-off" to a bad debt account versus a direct write-off of revenue.
c) The employee's utilization calculations will be impacted by changing the billing status of the transactions and reducing the corresponding revenue. we may need to update the utilization report to reflect these types of transactions differently.
2) use the "special" transfer adjustment option to transfer the transaction from the originating billable task to a non-billable destination task on the project in question.
Pros:
a) the average user will easily see that the transaction in question has been reversed and b) the revenue subsequently written off by the negative revenue on the reversal transaction
c) an adjustment record will be created in the PA_Expend_Item_adj_activities table which will include the applicable adjustment activity code(s) (Transfer Back-out, Transfer Originating, Transfer Destination).
d) history of who created original and adjustments is available.
a reversing revenue entry will be made via e) the negative reversal entry created in the PA_Cust_Rev_Dist_Lines_All table.
Cons:
a) the original transaction is being altered (transferred) by accounting. the integrity of the transaction as it was submitted by the source employee may be compromised.
b) there is no easy way for the average end user to know where the transaction was transferred to. the information is available via ad hoc reporting from database tables but looking at expenditure inquiry for a given project you will not be able to determine where the transaction went if it was transferred to another task and many tasks exist or if it was transferred to another project entirely.
c) The revenue write-off will be charged to the same accounts (revenue and inventory) that the original transaction was booked to but in reverse. we don't have the ability to deflect the "write-off" to a bad debt account versus a direct write-off of revenue.
d) The employee's utilization calculations will be impacted by changing the billing status of the transactions and reducing the corresponding revenue. we may need to update the utilization report to reflect these types of transactions differently.
e) As a common practice, each project will need at least one "non-billable" task to capture such write-off transfers.
3) use a write-off event (both revenue and billing) to reduce the project by the aggregate amount of all transactions in question.
Pros:
a) employee specific transactions and ultimately utilization results will not be impacted by the independent event transaction.
b) by modifying our autoaccounting rules we will be able to book the "write-off" to an account other than a revenue account. (I believe, more research necessary)
Cons:
a) No link back to actual transactions.
b) original transactions will remain untouched and will appear as though they were billed and will show up on the invoice and detail reports to the client along with an aggregated event for the total write-off amount.
Any thoughts or opinions you can provide about the best practice in Oracle will be greatly appreciated.
null

Answer 1

Diana,
Here's another response from a (very) senior Projects consultant. Her comments are in CAPS, so they can be dinstinguished from your comments:
"I recommend following the approach she outlines in Section 2, with the following additions:
SECTION 2) use the "special" transfer adjustment option to transfer the Transaction from the originating billable task to a non-billable Destination task on the project in question. CORRECT.
A) SET UP THE WBS TO HAVE A TOP LEVEL NON-BILLABLE TASK, ON EVERY PROJECT, WITH A TASK NUMBER OF :"WRITE-OFF".
B) WRITE AUTOACCOUNTING RULE , BASED ON TASK NUMBER, TO ENSURE THAT ANY TRANSACTIONS CHARGED (TRANSFERRED) TO "WRITE-OFF" TASK WILL BE POSTED TO A "WRITE-OFF/BAD DEBT" ACCT IN GENERAL LEDGER.
C) CREATE A DFF AT THE EXPENDITURE ITEM LEVEL WHICH CAN BE POPULATED AT THE TIME OF TRANSFER, TO INDICATE WHERE THE TRX IS BEING TRANSFERRED TO. IT IS TRUE THAT TRANSFER ACTIVITY REPORT WILL TELL YOU THIS AS WELL, BUT IF YOU
WANT TO SEE IT ONLINE DURING EXPEND. INQ, THEN DFF IS FINE.
D) AS TO CONCERNS ABOUT "THE INTEGRITY" OF THE TRANSACTION AS IT IS SUBMITTED BY THE EMPLOYEE BEING COMPROMISED, THIS IS CERTAINLY POSSIBLE, BUT IF THIS IS A SERIOUS BUSINESS CONCERN, THEN I WOULD CONSIDER CREATING AN ALERT TO THE EMPLOYEE WHO ENTERED THE ORIGINAL TRX, ADVISING THEM OF THE CHANGE AND REQUESTING THEIR REVIEW AND OR APPROVAL OF THE TRANSFERRED TRX. I CAN SEE THIS BECOMING QUITE CUMBERSOME THOUGH, AND, OVERALL, ACCOUNTING DEPARTMENTS MANIPULATE TRANSACTIONS FOR ACCOUNTING PURPOSES ALL THE TIME AS STANDARD PRACTICE, SO I'M NOT SURE WHY THIS IS AN ISSUE HERE.
E) AND LASTLY, IT IS TRUE THAT AS A COMMON PRACTICE, EACH PROJECT WILL NEED A
'WRITE-OFF" TASK AS A STANDARD PART OF IT'S WBS-- SO WHAT? IT'S JUST ONE MORE TASK IN YOUR WBS. BUILD IT INTO YOUR PROJECT TEMPLATES, AND MAKE IT NOT CHARGEABLE UNTIL WRITE OFFS BECOME NECESSARY. AS TO UTILIZATION, THERE IS NOT ENOUGH INFO IN THE CLIENT QUESTION TO ADDRESS THAT ISSUE PROPERLY.
THAT'S ABOUT IT. HOPE THIS HELPS.
BEST REGARDS, PAT"
null