trending_up Reporting

OBI Dashboard: Expense Requests and SU Card Activity (ERR)

The Expense Requests and SU Card Activity (ERR) dashboard provides information about transactions created in the Expense Requests and PCard systems. This includes purchasing card (PCard), travel card (TCard), expense reports, visitor reimbursements (includes Easy Pay and digital payments), advances, petty cash, non-PO payments and legacy iOU transactions.

Launch OBI Expense Requests and SU Card Activity Dashboard

Click this link......for reports about 
Expense RequestsTransaction details of all expense reports, advances, visitor reimbursements (including Stanford Easy Pay and digital payment methods), non-PO payments (including honoraria and human subjects) , petty cash and legacy iOU transactions. 
Expense Requests - AgingPending expense requests grouped by aging periods and outstanding status.  
Credit Card TransactionsDetails of credit card charges for university purchasing card (PCard) and travel card (TCard) transactions. Displays credit card information for those used in the listed transactions. 
Credit Card Transactions - Aging Transaction details of PCard and TCard charges not yet posted to a PTA , grouped by age periods and outstanding status. 
TCard Personal Transactions Payment DueSummary of personal expenses charged to a TCard for which payment is still due to the university. 
AdvancesTransaction details of advances, similar to Expense Requests tab, and includes the expense requests to which advances have been applied. 
Advances - AgingTransaction details of advances not yet expensed (i.e. not on an expense request that has been posted to a PTA). Transactions are grouped by aging periods and outstanding status. 
 Advances - Force ClearedTransaction details of advances that have been force cleared.  Includes all transactions associated with the original advance, the force cleared advance and the associated fee. 
Petty Cash Replenishment Transaction DetailPetty cash fund replenishment transaction details. 
Expense Request Efficacy DashboardDisplays expense request approval and rejection rates, processing times, and request statuses across employee roles and individuals to identify opportunities for process improvement. 
PCard Efficacy DashboardPCard transaction approval and withdrawal/return rates, processing stats and details by employee role and name, expenditure types and merchants. 
Force Clear Metrics DashboardSummary of force cleared travel card transactions (TCard), purchasing cards (PCard), and advances by organization and employee.  
SU Credit Card CustodianNon-customizable, BI Publisher listing of SU credit cards, names of cardholders, verifiers and approvers, transaction limit amounts, last four digits of card number and guarantee PTA number. 

 

This report displays transaction details of all advances, expense reports, visitor reimbursements, non-PO payments, including honoraria and human subjects, petty cash and legacy iOU transactions. Includes information about types of payment, such as Stanford Easy Pay and digital payments.

Launch OBI Expense Requests

  • What is the status of an expense request for a particular traveler?
  • Which expense requests were submitted for a particular event, and to what PTAs were they charged?
  • Which advance was used against a particular expense request, and how much of the advance was applied?
  • Which non-PO payments are charging my PTA?

To retrieve results, follow the Selection Criteria instructions near the top of the screen.  For additional guidance refer to  Using Selection Criteria for OBI Reports.

  • If searching by Expense Request Transaction Number or SU Credit Card Transaction ID Number, no dates are required.
  • For Expense Request Transaction Number, use the proper alpha character prefix. Refer to the Understanding the Data section to see the available prefixes.
  • Guarantee PTA Number is the PTA where travel card charges accumulate until they post to a PTA as part of an expense reimbursement. The guarantee PTA is specified during the credit card application process.
  • Supplier Name is the individual who is getting the reimbursement, advance or non-PO payment.  For Stanford Easy Pay transactions, use Payment Recipient Full Name or Payment Recipient Email Address.

If Expenditure Item Dates is used as selection criteria, all the transaction lines of specific expense requests may not be captured.

Expense Request Transactions 

This section displays details and status information for all types of expense requests, however it does not include those that have been saved but never submitted for approval.

To reconcile Expense Requests with the Consolidated Expenditure Reporting Expenditure Detail report, choose GL Period Name as selection criterion and use the Expenditure Reconciliation view.

 Expense Request Transactions Summary

This section displays the number of expense request transactions and the total dollar amount of all the expense requests listed in the Expense Request Transactions section.

The OBI ERR Expense Request Category field maps to Oracle Expense Request System (ERS) Type, see table below. The initial alpha characters of an ERR Expense Request Transaction Number uniquely identify ERR Expense Request Category.

ERR transactions are further defined by Expense Request Transaction Type Description which maps to Oracle Expense Request System (ERS) Category. For guidance on determining ERS types and categories, refer to Expense Request System Help.
 

OBI ERR Expense Request CategoryInitial characters of transaction #Oracle ERS Type
Expense ReportERExpense Report/Employee, Student
Stanford Easy PayEZP

Expense Report /Visitor (Reimbursement)

Non-PO Payments (Honoraria)

Advance RequestADVExpense Report/Employee, Student (Request Advance)
Non-PO Payment RequestPRNon-PO Payments (all other types)
Petty Cash Replenishment RequestPCPetty Cash/Replenishment
Visitor Reimbursement RequestVRLegacy Expense Report/Non-SU Payee
Digital PaymentDPLegacy Digital Payments/Non-SU Payee
OtherA or RLegacy iOU system

 

Use this report to track expense requests that are still in process and not fully posted.  This report  tracks expense requests once they are submitted for approval until they post to a PTA as an expenditure.  

  • Submitted expense reports are displayed within the appropriate aging bucket.
  • Expense requests that have moved beyond local approval are displayed as outstanding.
  • After the expense request has moved past audit review, posted, and paid, it is no longer visible on the aging report but is still available on the Expense Request report.

For more information on the expense request workflow and how it relates to this report, refer to Topic Overview: Managing Aging and Outstanding Expense Transactions-Aging Reimbursements of Personal Funds.

Launch OBI Expense Requests - Aging

  • Which transactions are aging and need action?
  • Which transactions are outstanding (approved locally but pending other actions)?
  • Are any expense requests stalled in their workflow progression and need resolution?
  • Who is the approver or preparer to follow up with, based on the transaction status?

To retrieve results, follow the Selection Criteria instructions near the top of the screen.  For additional guidance refer to  Using Selection Criteria for OBI Reports.

  • Because there are no date prompts, it displays all expense requests that that have not yet been posted to a PTA as expenditures.
  • For Expense Request Transaction Number, use the proper alpha character prefix. Refer to the Understanding the Data section to see the available prefixes.
  • Supplier Name is the individual who is getting the reimbursement, advance, or non-PO payment. For Stanford Easy Pay transactions, use Payment Recipient Full Name or Payment Recipient Email Address.

Expense Requests - Aging & Outstanding 

This report displays details and status information. It receives data from the Expense Request module in Oracle Financials for all transactions, except those that have been saved but never submitted. The report displays the transaction dollar amounts in columns based on the number of days from the expense request end date up through local approval, at which point the Outstanding columns indicate where it is in central processing.

Expense Requests Transaction Summary

This section displays the number of expense request transactions and the total dollar amount of all the expense requests listed in the Expense Requests - Aging & Outstanding section.

Expense Request Category 

The OBI ERR Expense Request Category field maps to Oracle Expense Request System (ERS) Type, see table below. The initial alpha characters of an ERR Expense Request Transaction Number uniquely identify ERR Expense Request Category.

ERR transactions are further defined by Expense Request Transaction Type Description which maps to Oracle Expense Request System (ERS) Category. For guidance on determining ERS types and categories, refer to Expense Request System Help.
 

OBI ERR Expense Request CategoryInitial characters of transaction #Oracle ERS Type
Expense ReportERExpense Report/Employee, Student
Stanford Easy PayEZP

Expense Report /Visitor (Reimbursement)

Non-PO Payments (Honoraria)

Advance RequestADVExpense Report/Employee, Student (Request Advance)
Non-PO Payment RequestPRNon-PO Payments (all other types)
Petty Cash Replenishment RequestPCPetty Cash/Replenishment
Visitor Reimbursement RequestVRLegacy Expense Report/Non-SU Payee
Digital PaymentDPLegacy Digital Payments/Non-SU Payee
OtherA or RLegacy iOU system

 

This report displays transaction details of credit card charges in separate sections for university purchasing card (PCard) and travel card (TCard) transactions as well as credit card information for cards used in the transactions.

Refer to Topic Overview: Stanford Purchasing Cards  and Topic Overview: Stanford Travel Card Program for more information about the university's credit card programs.

 

Launch OBI Credit Card Transactions

  • What charges are on my organization’s travel card and PCard?
  • What are the transaction details, counts and amounts for the cardholders in my organization for a specific time period?
  • Which transactions were force approved (force cleared) in a particular range of GL periods and may need to be journaled to their proper PTAE?

To retrieve results, follow the Selection Criteria instructions near the top of the screen.  For additional guidance refer to Using Selection Criteria for OBI Reports.

 
Description and Status
  • Use Credit Card Program Description to filter by type of credit card transaction (Tcard or Pcard).
    • For Tcard transactions not yet linked to an expense request that has been submitted for approval, use "Unknown" for the Expense Request Status Description.
    • For Tcard transactions already linked to an expense request that has been submitted for approval, use the Expense Request Status Description  for the desired status:  Paid, Pending Approval, Rejected.
    • To retrieve any Tcard or Pcard transactions that have been force cleared, specify "Forced Approved" for SU Credit Card Transaction Status Description.
Transaction Number
  • If searching by SU Credit Card Transaction ID Number, no dates are required. This transaction ID number can be for the PCard Mastercard, TCard Mastercard or TCard American Express.
  • If searching by Expense Request Transaction Number, no dates are required. Only TCard charges related to the specified expense request will be returned.
Person Perspective
  • Current Verifier is the person currently assigned as the verifier for the credit card.  This is changed when personnel changes are updated using the Credit Card Profile Change Request and is reflected in the Credit Card Custodian report.
  • Verifier is the person designated as the credit card verifier when the credit card purchase transaction occurred and does not change. This applies to both TCard and PCard transactions.
  • Preparer applies only to TCard transactions and is the person who initially submits the associated expense request for approval.
  • SU Credit Card Holder is the name printed on the credit card; for department cards it is the name of the department.
  • SU Credit Card Custodian is the person who has possession of the card. This is most relevant for department cards because they do not have a person’s name on them. For individual cards, the credit card custodian is also the cardholder.
Guarantee PTA 
  • Guarantee PTA Number is an attribute of the PCard and/or TCard used for a transaction and can be different from the transaction PTA Number.
    • For TCards, it is the PTA where charges are accumulated until they are posted as an expenditure on an expense request.
    • For PCards, it is the PTA to which charges will be force-cleared if they are not verified and expensed to a PTA within an appropriate time frame.
Personal Expenses

Reporting Personal Expense Indicator equal to "Yes" retrieves credit card transactions that have a verified personal expense. Include the fields referenced below to see the actual values per transaction.

  • For TCards, Personal Amount is not equal to zero.
  • For PCards, SU Credit Card Transaction Personal Expense Indicator is Yes or Partial.  

 

Use the Expanded with PTAE view to determine which credit card transactions have been force cleared (aka force approved) and to display the administrative fee charged. Refer to How To: Find Force Cleared PCard and TCard Transactions.

TCard Transactions

This section displays travel card transactions throughout their entire workflows. This includes TCard transactions that have or have not been applied to an expense request.

PCard Transactions

This section displays all purchase card transactions. This includes PCard transactions that have not been verified.

Credit Card Information

This section displays information about the TCards and PCards used, including the card custodian, holder and current verifier, along with the guarantee PTA and credit limit amounts.  

Only cards that were used in the transactions listed in the TCard and PCard Transaction Reports will be displayed. Deactivated cards could be displayed if they were used in one of the transactions listed. This may differ from what is shown on the SU Credit Card Custodian Report.

To understand which date selection criteria to use, refer to the following table. 
 

FieldDescription
Expense Incurred Date
The date the credit card transaction occurred.
SU Credit Card Posted DateThe date the transaction posts from the bank to the Expense Requests module (TCards) or the PCard module (PCards) within Oracle Financials.
SU Credit Card Expense End DateThe date entered by the preparer for TCard transactions in the Expense Requests module to specify the last expense date for all transactions related to the event/trip.  This supersedes the default of Expense Incurred Date to become the new date used for calculating aging. 
Expense Request End DateThe latest expenditure item date of all the transactions included in the expense request. This field is not displayed by default in the aging report but can be revealed by using the include command.
Submitted DateFor PCards, it is the date the transaction completed verification and was submitted for approval. For TCards, it is the date the associated expense request was submitted for approval.

 

Use this report to track credit card  (TCard and PCard) transactions that are still in process and not yet posted to a PTA as an expenditure.  

  • Credit card transactions are displayed in aging buckets starting after the initial purchase and stay on until the
    • TCard is applied to an expense request that has been approved, posted and paid
    • PCard is verified and approved
  • After the credit card transaction has been fully cleared, it is no longer visible on the aging report but is still available on the Credit Card Transactions report.

For more information on the travel card transaction workflow and how it relates to the TCard Transactions Aging & Outstanding report, refer to Topic Overview: Managing Aging and Outstanding Expense Transactions-Aging Travel Card (Tcard) Transactions.

For more information on the purchasing card transaction workflow and how it relates to the PCard Transactions Aging report, refer to Topic Overview: Managing Aging and Outstanding Expense Transactions-Aging Purchasing Card (Pcard) Transactions .

Launch OBI Credit Card Transactions - Aging 

  • What charges on my organization’s travel card are not yet posted to a PTA, i.e., are aging, and how old are they?
  • Which aging transactions are pending verification or local approval and who are the employees whose actions are pending?
  • Which aging transactions are outstanding (approved locally but pending other actions)?
  • Which aging transactions are disputed?
  • Which aging transactions do not have Expense End Dates assigned?
  • Which aging transactions have a verifier or a card custodian that is no longer in their role at Stanford?
  • Which transactions have been rejected or returned to a preparer who is no longer the current verifier?

To retrieve results, follow the Selection Criteria instructions near the top of the screen.  For additional guidance refer to Using Selection Criteria for OBI Reports.

 
Dates

Because there are no date prompts, it displays all credit card transactions that have not yet been posted to a PTA as expenditures.

Description and Status
  • To filter by type of credit card transaction (TCard or PCard), use Credit Card Program Description.
    • For Tcard transactions not yet linked to an expense request that has been submitted for approval, use "Unknown" for the Expense Request Status Description.
    • For  Tcard transactions already linked to an expense request that has been submitted for approval, use the Expense Request Status Description for the desired status:  Paid, Pending Approval, Rejected
  • To search by status for a Pcard transaction, specify "SU Pcard" for Credit Card Program Description and use SU Credit Card Transaction Status Description.
Transaction Number
  • If searching by SU Credit Card Transaction ID Number, no dates are required. This transaction ID number can be any of the listed credit card programs.
  • If searching by Expense Request Transaction Number, no dates are required. Only TCard charges related to the specified expense request will be returned.
Person Perspective
  • Current Verifier;is the person currently assigned to verify transactions for the credit card. This assignment is changed when personnel changes are updated using the\Credit Card Profile Change Request and is reflected in the Credit Card Custodian report.
  • Verifier is the person who is designated as the credit card verifier when the credit card purchase occurred and does not change.  This applies to  both TCard and PCard transactions.
  • Preparer applies only to TCard transactions and is the person who initially submits the associated expense request for approval.
  • SU Credit Card Holder Name is the name printed on the credit card; for department cards, it is the name of the department.
  • SU Credit Card Custodian Full Name is the person who has possession of the card. This is most relevant for department cards because they do not have a person’s name on them. For individual cards, the custodian is also the card holder.
Guarantee PTA
  • Guarantee PTA Number is an attribute of the PCard and/or TCard used for a transaction and can be different from the transaction PTA Number.
    • For TCards, it is the PTA where charges are accumulated until they are posted as an expenditure on an expense request.
    • For PCards, it is the PTA to which charges will be force cleared if they are not verified and expensed to a PTA within an appropriate time frame.
Personal Expenses
  • Reporting Personal Expense Indicator allows you to select Yes if you just want to view aging credit card transactions that have been deemed either a full or partial personal expense, and the card custodian or supplier still needs to reimburse the university.  
    • For TCards, "Personal Amount" is not equal to zero.
    • For TCards, this report will only show those expense requests where only a part of the expense request amount is a personal expense.  To get the full picture of personal expenses still pending reimbursement, including when the full expense request is a personal expense charged to the Tcard, use the TCard Personal Transactions Payment Due report.

TCard Transactions - Aging & Outstanding

This section displays travel card transactions that have not been applied to an expense reimbursement or are applied to an expense reimbursement that has not been posted to a PTA. This report displays the transaction dollar amounts in buckets, based on their age prior to local approval or the status of their associated expense request while being processed centrally.

 
Identifying and Resolving Stalled TCard Transactions

Use the Expanded-Action Needed view to identify stalled TCard transactions due to inactive personnel. You can verify if the current verifier or SU credit card custodian is no longer active by the relevant Employment or Job Status Indicator column.  

For TCard transactions on rejected or returned expense requests compare the names of the current verifier and preparer of the expense request.  If these roles are assigned to different people, the expense request and associated TCard transactions will not be visible to the current verifier in Expense Requests to correct and resubmit the expense request.  For guidance on how to resolve this, refer to Resource: Resolving Outstanding Expense Requests and Aging Transactions.

Credit Card Transactions Reports – PCard - Aging

This section displays all outstanding purchase card transactions, per the selection criteria, throughout their approval workflow utilizing age buckets. This includes PCard transactions that have not been verified.

Use the Expanded-Action Needed view to identify PCard transactions that have stalled because the current verifier or card custodian is no longer active, identified by the relevant Employment or Job Status Indicator column.  

Travel Card Transaction Aging

Aging days are calculated as today’s date minus the end date. The end date is pulled from one of three different fields in the following order based on where it is in the expense request process:

  • SU Credit Card Posted Date reflects when the transaction posts to the Expense Requests module.
  • SU Credit Card Expense End Date is the estimated end date of the trip and is entered by the preparer against the TCard transaction.
  • Expense Request End Date is the derived date that indicates the latest transaction date for all the transactions on the expense report.

For more information on the travel card transaction workflow and how it relates to the TCard Transactions Aging & Outstanding report refer to Topic Overview: Managing Aging and Outstanding Expense Transactions-Aging Travel Card (Tcard) Transactions.

Purchasing Card Transaction Aging

PCard transaction aging starts from the SU Credit Card Posted Date until it completes local approval. 

For more information on the purchasing card transaction workflow and how it relates to the PCard Transactions Aging report refer to Topic Overview: Managing Aging and Outstanding Expense Transactions- Aging Purchasing Card (Pcard) Transactions.

Personal Charges

Cardholders must reimburse the university for any personal expenses charged on university credit cards. To see these charges or indicators of such charges, the following fields must be included:

TCard: Personal Amount displays the dollar amount that needs to be reimbursed to the university.

PCard: SU Credit Card Transaction Personal Expense Indicator indicates that the transaction consists entirely or partially of a personal expense.

Employment Status Indicator

This indicator appears for the current verifier, current verifier supervisor, and SU credit card custodian supervisor displaying either "Y" or "N". 

  • Y = Current Employee: Indicates the individual is an active, permanent employee
  • N = Non-Permanent Worker: May indicate either an inactive employee OR an active temporary/student worker, even though they are a valid person in the role. Current verifiers with N values must be individually assessed.

Job Status

Pertains to SU Credit Card Custodian and can be  "Active" or "Inactive".

 

 

Summary of personal expenses charged to a TCard for which payment is due to the university. Failure to submit an expense report within 60 days of the date of a transaction may result in expenditures reported as taxable income to the individual incurring the expense.

Refer to Topic Overview: Stanford Travel Card (TCard) Program for more information.

Launch OBI TCard Personal Transactions Payment Due 

  • For my org or PTA, who still has outstanding personal charges made on a TCard that have not been reimbursed and posted?
  • What personal amount has not yet been reimbursed?
  • What is the aging number of days for these unreimbursed personal charges?

To retrieve results, follow the Selection Criteria instructions near the top of the screen.  For additional guidance refer to Using Selection Criteria for OBI Reports.

  • Supplier Name is the individual who made the personal charge and is responsible for submitting a reimbursement to clear it.

Displays the supplier name, expense request transaction number, the AP Invoice Days Aging and the AP Invoice Total Personal Amount  along with the other details about the expense request.  This report will show expense requests where only a part of the amount is a personal expense and when the entire expense request is a personal expense.

This report was created using the AP Invoices and Payments subject area, which allows visibility to personal expenses that are still waiting for reimbursement to Stanford. When the entire expense request consists of personal TCard charges, the transaction is posted to a central PFOO as 11545-STANFORD PREPAID TRAVEL CARD,  resulting in those expense requests not being visible in reports using the Expense Request subject area.  

For more information on the travel card transaction workflow and how it relates to this report refer to Managing Aging and Outstanding Expense Transactions.  For guidance on reimbursing the university, refer to Return Personal Expenses Charged to a Travel Card.

Displays transaction details of advances and lists any expense requests to which advances have been applied.

Launch OBI Advances

  • For a particular advance, which expense requests has it been applied to, and is there an outstanding unapplied balance to be used before another advance for that employee is created?
  • Do any of the employees in my organization have a balance on one of their advances that should be refunded?
  • Have any of the advances been force cleared and need to be journaled to their proper PTAE?

To retrieve results, follow the Selection Criteria instructions near the top of the screen.  For additional guidance refer to Using Selection Criteria for OBI Reports.

  • The Expense Request Transaction Number applies only to advances (ADV). No date is required with this selection criteria. To view expense request details, use the Expense Requests tab.
  • Expense Request Transaction Status Description is the status of the advance itself and not of any related expense requests.
  • Supplier Name is the name of the person receiving the advance.

Advances

  • Displays details on advance transactions except those that have been saved but never submitted; includes uncleared, partially cleared and cleared advances.
  • Displays expense requests to which the advance has been applied and for what amount.
  • Shows the outstanding balance still available on the advance.
  • Displays advance amounts returned by the employee.
  • The outstanding advance balance will not reflect associated expense requests that have not been fully approved.

 

Advance Dates
FieldDescription
Expense Incurred Date/Expenditure Item DateThe date entered in the Expense Request system in Oracle when creating the advance.
Advance Expected Clearing DateThe expected date that the travel is to be completed; it is specified when creating the advance.
Submitted DateDuring the creation of the advance, the date it was submitted for approval.

The Advance-Aging report displays details of advances that are not completely cleared.

  • Each amount applied from an advance to an expense report is listed on a separate line.  
  • Any unapplied amount from the advance is displayed within the appropriate aging bucket.  
  • After the advance has been fully cleared by one or more expense requests, it is no longer visible on the aging report but is still available on the Advances report.

For more information on the advance and expense request workflow and how it relates to this report, refer to Topic Overview: Managing Aging and Outstanding Expense Transactions.

Launch OBI Advances - Aging

  • Which advances are uncleared?
  • Which advance balances are in jeopardy of exceeding 60 days?
  • Which advances have exceeded 60 days, to whom, and for how much?
  • Which advances have a preparer or a supplier (person who received the advance) that is no longer in their role at Stanford?

To retrieve results, follow the Selection Criteria instructions near the top of the screen.  For additional guidance refer to Using Selection Criteria for OBI Reports.

  • Because there are no date prompts, it displays all uncleared advances.
  • The Expense Request Transaction Number applies only to advances (ADV).  Expense Request Transaction Status Description is the status of the advance itself and not of any related expense requests.
  • Supplier Name is the name of the person receiving the advance.

Advances - Aging

Displays transaction details of advances not yet fully expensed, i.e., ones that have a remaining balance not on an expense request that has been posted to a PTA. Transactions and unapplied amounts are displayed by aging bucket. 

The advance balance is not adjusted until the expense request to which it is applied has been posted to a PTA.

 
Identifying and Resolving Stalled Advances

Use the Expanded-Action Needed view to identify advances that have stalled because a preparer or supplier (person who received the advance) is no longer active by the relevant Employment Status Indicator column.

Employment Status Indicator 

This indicator appears for the preparer and supplier displaying either "Y" or "N". 

  • Y = Current Employee: Indicates the individual is an active, permanent employee
  • N = Non-Permanent Worker: May indicate either an inactive employee OR an active temporary/student worker, even though they are a valid person in the role. Current verifiers with N values must be individually assessed. Transactions with an inactive supplier indicates the person who received the advance is no longer an employee and you should submit an Expense Requests system support request to clear this. 

For more information on the advance and expense request workflow and how it relates to this report, refer to Topic Overview: Managing Aging and Outstanding Expense Transactions.

Displays advances that have been force cleared by Financial Management Services (FMS) as a result of not being fully applied to an expense request or the unused advance funds not returned within 60 days of their expected clearing dates. This report includes transaction details of advances that have been force cleared along with transactions associated with the original advance and the force cleared advance, including the force clear fee.

Refer to How to Find Force Cleared Advance Transactions for instructions on how to use this report to identify force cleared advances and the follow-up steps to collect any advance reimbursements, upload documentation related to the advance, and the final iJournal dispositions for the force cleared charges. 

LAUNCH OBI ADVANCES - FORCE CLEARED

  • What are the advances that have been force cleared and may need to be journaled to their proper PTAE?
  • How much was charged to force clear advances?
  • How many advances were force cleared?

To retrieve results, follow the Selection Criteria instructions near the top of the screen.  For additional guidance refer to Using Selection Criteria for OBI Reports.

Advances - Force Cleared

Displays the number of advances that have been force cleared, as well as the total of the force clear fees that were charged.

Displays the AP Invoices related to advances that have been force cleared.   The AP Invoice Number  uses the same identifier as the related  Expense Request or Advance transaction. 

  • Original advance number (e.g. ADV123456) and associated details
  • Expense requests, if any, that have had that advance applied
  • Any returns of unused money (ADV123456RUM)
  • Forced cleared transaction (designated with the original advance number with FC appended (e.g. ADV123456FC)
  • Forced clear transaction fee for each force cleared advance
Viewing Force Cleared Transactions in other OBI ERR Dashboard Reports
  • Force cleared transactions are not visible in the Expense Requests report or Advances report.

  • The force cleared amount is included in the Employee Advance Returned Amount column in the Advances report, along with any other employee returned amounts. 

Viewing Force Cleared Transactions in OBI Procure to Pay (P2P) AP Invoices Report
  • Force cleared transactions have associated invoices in the Procure to Pay Reporting  - AP Invoices report.  These invoice numbers have the advance number with FC appended (e.g. ADV123456FC).
  • The force cleared transaction consists of:
    • the reversal of the unused balance of the advance from the original PTA using expenditure type 11540-ADVANCE
    • the posting of the advance balance to the AP Default PTA using 52415-DOMESTIC TRAVEL UNALW
    • the posting of the $35 force clearing fee to the AP Default PTA using 58510-INTERDEPT CHGS TO FR OTH DPT 1

When unused advance money is returned by the employee, the AP Invoice for that transaction is designated as the advance number with RUM appended (e.g. ADV123456RUM

Listing of petty cash holders and detail of replenishment transactions.

Launch OBI Petty Cash Replenishment Transaction Detail

  • Who is the custodian for the petty cash account for my organization?
  • What reimbursements are being processed using petty cash?

To retrieve results, follow the Selection Criteria instructions near the top of the screen.  For additional guidance refer to Using Selection Criteria for OBI Reports.

Petty Cash Replenishment Transactions

Displays information about the petty cash account including the petty cash fund name, custodian and funded amount for the given selection criteria.

Displays the number of petty cash replenishment transactions and the total reimbursement amount for the selection criteria entered.

The Expense Request Efficacy (ERE) Dashboard provides reporting and analysis to support expense request processing management. The dashboard tracks approval and rejection rates, rejection reasons, processing lead times and throughput metrics to help identify areas for process improvement. Data is displayed in tabular and graphical formats.

Refer to the  ERE dashboard  reporting page for details.

The PCard Efficacy (PCE) Dashboard provides PCard transaction data to monitor and analyze PCard transaction processing.  The data includes withdrawal/return rates, processing statistics and details by employee role and name, expenditure types and merchants. Data is provided in tabular and graphical formats.

Refer to the  PCE dashboard  reporting page for details.

The OBI Force Clear Metrics (FCM) Dashboard provides budget units and organizations summary level reporting of university credit card transactions (PCard and TCard) and advances that have been force cleared.  This provides visibility where training or reinforcement of policy is needed to prevent future force clear transactions. 

Refer to the Force Clear Metrics  Dashboard reporting page for details.

Non-customizable, BI Publisher listing of active, inactive and suspended credit cards(PCard & Tcard), The report includes details about card custodians, card holders, verifiers and approvers, along with transaction limits, last four digits of credit card numbers and guarantee PTA information.

Refer to Topic Overview: Stanford Purchasing Cards for more information about the university's credit card programs.

Launch OBI SU Credit Card Custodian

  • Who has credit cards for my organization, and who are the verifiers for the cards?
  • What are the guarantee PTAs for the cards within my organization?
  • Do any former Stanford employees still have active credit cards linked to my organization?
  • Which credit cards have been suspended or closed?
  • Which cards do not have a verifier with active status?

To retrieve results, follow the  instructions on the first tab. 

  • Specifying an Inactive On date and Card Status = All returns all credit cards that were deactivated after that date, and includes credit cards that are still active.

For additional information for selection criteria, see BI Publisher Reports.

The Credit Card Custodian report requires that you select one of two tabs to view the results.

Displays a list of credit cards by the last four digits of the card numbers, and includes details about the custodian, cardholder, verifier, approver, card transaction limits and guarantee PTA.

Data Download - This tab provides a downloadable data version of the Custodians - Distributed Report.  

Name
  • SU Credit Card Holder is the name printed on the credit card; for department cards, it is the name of the department.
  • SU Credit Card Custodian is the person who has possession of the card. This is most relevant for department cards because they do not have a person’s name on them. For individual cards, the credit card custodian is also the credit cardholder.
  • Verifier is the person who is responsible for properly documenting and recording PCard and TCard/Expense Request transactions in Oracle Financials.
Guarantee PTA
  • Guarantee PTA Number is an attribute of the credit card used for a transaction and can be different from the transaction PTA Number.
    • For TCards, it is the PTA where charges are accumulated until they are posted as an expenditure on an expense request.
    • For PCards, it is the PTA to which charges will be force-cleared if they are not verified and expensed to a PTA within an appropriate time frame.
Job Status

This value exists for both Verifier and SU Credit Card Custodian and can be either Active or Inactive. While Active means that the person is a current employee, Inactive will appear for a temp worker or student worker, even if they are the valid current person in the role. Records with Inactive values must be individually assessed to determine whether there is a valid person currently in the role.

 

Last Updated: Dec 4, 2025
Submit feedback about this page

Questions?

arrow_upward
Back to Top