Grants & Customer Contracts: The grants customer contracts and project costing implementation are designed to make your life easier by collecting all your expense transactions automatically, create accounting entries, and tee up billing automatically. Revenue recognition, receivables, and application of payments tie together seamlessly.


Users should activate grant customer contracts only when they are ready for the system to recognize revenue and tee off the process for system billing. However, we know adoption has lagged and users have billed offline and manually recognized revenue even when they had active customer contracts from the go-live conversion.


In cases where the user has not yet received payment for billing done offline, or they have not already reconciled the payment to the bank, it’s possible to run grant billing as usual, and to apply the eventual payment to the receivable generated through the normal process. If policies allow for users to continue having activated customer contracts but not use those contracts to bill, then this linked job aid can be followed to reverse overstated revenue already manually recognized and relieve the unbilled accounts receivable.


Below are two scenarios for the system generated accounting regarding grant customer contracts, the first discusses accounting based on normal system use, the second shows how accounting will flow if the user employs the attached job aid.


Scenario 1: Regular Grant Billing Using Financials:

 

1. After Expense Transaction or Allocation (System background batch process—GL updated several times per day): Journal ID begins CAPC%

Debit Unbilled AR (100040)

Credit Revenue (444999, 448999, or 449999)

 Dept, Fund, Authority, Project and Activity Inherit from expense transaction (Debit Expenditure, Credit Cash). Account is the only value that changes at each step.

 

2. Billing (User process, step 4 in billing—GL updated several times per day): Journal ID begins BI%

Debit AR (100029)

Credit Unbilled AR (100040)

Dept, Fund, Authority, Project and Activity Inherit from expense transaction (Debit Expenditure, Credit Cash). Account is the only value that changes at each step.

 

3. Deposit Application (User process—GL updated several times per day): Journal ID begins AR%

Debit Cash (1XXXXX, specific cash account is automatically identified depending on deposit Bank Account)

Credit AR (100029)

Dept, Fund, Authority, Project and Activity Inherit from expense transaction (Debit Expenditure, Credit Cash). Account is the only value that changes at each step.


Scenario 2: Job Aid - Billing occurred outside of Financials and Revenue was manually recognized (and overstated):

 

1. After Expense Transaction or Allocation (System background batch process—GL updated several times per day): Journal ID begins CAPC%

Debit Unbilled AR (100040)

Credit Revenue (444999, 448999, or 449999)

 Dept, Fund, Authority, Project and Activity Inherit from expense transaction (Debit Expenditure, Credit Cash). Account is the only value that changes at each step.

 

2. Billing (User process, step 4 in billing—GL updated several times per day): Journal ID begins BI%

Debit AR (100029)

Credit Unbilled AR (100040)

Dept, Fund, Authority, Project and Activity Inherit from expense transaction (Debit Expenditure, Credit Cash). Account is the only value that changes at each step.

 

3. ALTERNATIVE to Deposit Application 

Adjust Bill: Journal ID begins CAPC%

Debit Revenue (444999, 448999, or 449999)

Credit AR (100029)

Dept, Fund, Authority, Project and Activity Inherit from expense transaction (Debit Expenditure, Credit Cash). Account is the only value that changes at each step.