Frequently Asked Questions

This occurs when the report is too large to open on the desktop. The user should re-run the report, selecting the “Run to Library” button. When the report is done, it will display in the library.

No, not all MTS reports are stored under the MTS tab. They can display in any of the other tabs such as Amounts, Balances and the Admin.

If a common report does not appear on any tab, access to the report may be restricted. Contact the Bureau of the Fiscal Service to discuss gaining access to the report through ASR or receiving the report via e-mail.

Users can click the Schedule icon for a report to see the Next Scheduled Run date and time for any report.

The report will run at the time listed after the Monthly Treasury Statement has been published and released to the public.

Signing up for ASR with the user role of Agency Account Administrator will allow you to receive notifications when reports are run that identify inactive or suspended accounts belonging to your agency. The list of accounts will be sent to the e-mail address listed on your CARS user profile.

Reports with the “Owned by Agency” parameter are limited based on the agency identifier listed in the AID field of the account. Reports with the “Agency Responsible For” parameter are limited based on the agency identifier listed in the ATA field of the account. If no agency identifier is listed in the ATA field, the agency identifier listed in the AID field will be used.

It is okay to open the file by answering ‘Yes’ to the message. This occurs due to the transfer from the web to Excel.

Statement of Difference (SOD) is a new module in the Central Accounting Reporting System (CARS). SOD will replace the GOAL II/IAS Statement of Difference System, a part of the Treasury’s legacy reporting system. Designed for use by non- and partial reporters, SOD provides enhanced functionality by allowing Federal Program Agencies (FPAs) to view their Agency Location Codes (ALCs) for the purpose of identifying balance differences between agency and source system reporting.

Agencies must ensure that none of their ALCs have an existing uncleared Statement of Difference before they can become full reporters. The SOD report compares the Agency Balance and the Source System Balance. The Agency Balance is defined as data reported by agency users, and the Source System Balance is defined as data provided by source system files.

Check Issue Audit (CIA) is a new module in the Central Accounting Reporting System (CARS). Designed for use by Treasury and Non-Treasury Disbursing Officers that have authority to disburse payments. CIA provides enhanced functionality by allowing Federal Program Agencies (FPAs) to view their Agency Location Codes (ALCs) for the purpose of identifying out of balance conditions between agency and source system reporting. CIA will replace the manually generated CIA Report provided to Disbursing Officers via email and/or US Mail.

Agencies must ensure that none of their ALCs have a difference in Check Issue Audit before they can become full reporters. The CIA report compares the Agency Checks Issued and the Source System Checks Issued. The Agency Checks Issued is defined as data reported by agency users, and the Source System Checks Issued is defined as data provided by source system files.

Depends if the user is a FS Administrator (FMSA) or an Agency Reviewer (AR)

• FMSA will have access to all reports.
• AR views will depend on the Access Group (AGroup) associated with the users login credentials.

The Deposit Report Filter displays agency Statement of Transaction, Section III, Line 3, or Statement of Accountability, line 420 reporting and the CIR/PIR source system reporting. A Deposit difference is generated when the data reported by the agency does not agree with the data reported by the source system.

Selectable links are dependent on the Access Group (AGroup) associated with the users login credentials.

No, the SOD and CIA application is a report generator only.

No, the ALCs are prepopulated in a dropdown menu and selectable dependent on the Access Group (AGroup) associated with the users’ login credentials.

SOD and CIA modules are report generators only, that obtain transaction information from the SOD database which is updated daily.

Support Listings are on demand reports and can be viewed on line and printed. The Support Listings will consist of three separate reports:

• Collection Voucher and Payment Voucher will be identical except one listing is for all vouchers related to collections (CIR), and the other listing is for all vouchers related to payments (PIR Voucher).
• IPAC Support Listing provides all interagency transactions processed in the IPAC Application.

The Check Issued Audit Report Filter summarizes the agency Statement of Accountability, lines 210, 211 and/or 212 reporting and the TCIS (Level 8) source system reporting. An out of balance condition occurs when the data reported by the agency does not agree with the data reported by the source system.

A BETC is a code that the Central Accounting Reporting System (CARS, formerly the GWA system) uses for the type of activity you are reporting, such as payments, collections, investments, etc.

Examples of BETCs

• DISB
• DISBAJ
• COLL

List of BETCs

• Payables disbursement
• Payables disbursement adjustment
• Receivables collection

You must use the BETC along with the Treasury Account Symbol (TAS) and the dollar amounts to classify each transaction against the fund balance with Treasury. 

BETC replaces the transaction codes and standard sub-classes used in old central accounting reports, such as the Statements of Transactions (FMS Form 224) and the Undisbursed Ledger and Trial Balance Reports (FMS Forms 6653 and 6654).

Over 250 Non-Expenditure, Transfers, Borrowing, and Warrant Transactions.

Many BETCs are for Non-Expenditure, Transfers, Borrowing, and Warrant transactions. Because the CARS’ Agency Transaction Module (ATM) processes those transactions directly, those BETCs are automatically assigned behind the scenes in ATM.

Payment and Collection Transactions The remaining BETCs are for Payment and Collection transactions. You report those BETCs through interfacing systems, such as IPAC, PAM/SPS, or TRS. You must give those payment and collection BETCs when you report transactions through the interfacing systems.

We assign TAS to agencies, and we assign business events to TAS as defined by legislation.

For example, if your agency has legislated investment authority, then your TAS will have the BETC of “INVTSEC.” That allows you to report investment transactions.

You can see the existing TAS BETC relationships at these websites:
https://sam.for.fiscal.treasury.gov/sampublic/tasbetc.htm
http://www.fiscal.treasury.gov/cars/reference-and-guidance.html

A Treasury Account Symbol (TAS) is a code that allows us to identify critical information about each transaction that you report.

You give the relevant code by putting together the appropriate information for each of several parts (for example, agency identifier, fiscal year, main account number, sub-account number, and so on).

Because the new way of giving the right TAS for each transaction is made up of these parts (components), we call it a "Component TAS."

Federal Program Agencies that must report transactions to Treasury's Bureau of Fiscal Services through a system like IPAC or FMS 224 must give both a TAS and a Business Event Type Code (BETC) for each transaction.

Currently, FPAs report their TAS using a string format (e.g. 20X1801.1). Fiscal Service is adopting the Component TAS (Attachment B), in lieu of the String TAS (Attachment A). There are many benefits to using separate, component pieces, such as having the ability to sort, filter, and analyze based on each independent piece.

Within the TAS itself, there are three other changes to note:

The first change is the elimination of standard subclasses. This means that FPAs will report a TAS, without having to report sub classification of that TAS based on explicit transaction types (such as borrowings, investments, funds held outside the Treasury). Instead of the transaction type being reported as a standard subclass on the TAS, it will be reported as a business event separate from the TAS. For example, if an agency has Funds Held Outside the Treasury, they currently report TAS (41) 20X1234. In the GWA environment, they will report the TAS 20X1234 – without the (41) – but with a separate business event type code (BETC) of FHOTXD.

As a result, the subclass field is being renamed to "Sub-level Prefix" and will only be used for programmatic breakdowns of the TAS for Treasury publication purposes. Sub-level Prefixes have a unique meaning or a unique need for sub classification that is NOT based on transaction types or business events as described previously.

The other two significant changes to the TAS relate to the expansion of the department/agency codes and to the fiscal year fields. See Attachments for further details regarding these field changes.

The BETC indicates the type of transaction (for example, payment, collection, investment, and so on). The BETC replaces the part of the earlier TAS system that indicated the transaction type. The new Component TAS gives us the rest of the needed information.

You can see the existing BETC TAS relationships at these websites:
https://sam.for.fiscal.treasury.gov/sampublic/tasbetc.htm
http://www.fiscal.treasury.gov/cars/reference-and-guidance.html

The GWA Modernization Project redesigned the Rewrite Module to address design flaws, performance issues, environment stability, and validation concerns.

Also, the Rewrite Module used outdated technology creating a mixed environment and requiring a substantial amount of re-testing after implementation.

The redesign effort also enables the project to eliminate the dependencies that other GWA Modules had on the implementation of the Rewrite Module. We also re-named the Rewrite Module the Authority Transaction Module (ATM) to more accurately reflect the type of transactions involved in each application.

The first build of ATM consisted of the second release of the Non-Expenditure Transfers, Borrowing from Treasury, and Warrant Journal Voucher applications and was completed in August 2006.

The second build of ATM consisted of the first release of the Appropriation Warrant application and was completed in 2007.

The Non-Expenditure Transfers (NET) application provides an automated process for creating, approving, and reviewing NET transactions.

The application eliminates the manual processing and approvals of SF 1151 documents and provides you with the ability to transmit Non-Expenditure transactions via the Internet using a standard browser, Microsoft Internet Explorer. You can track and view transactions from the time of initial entry until the transaction is posted to Treasury's Central Accounting System (STAR).

Borrowing from Treasury is a NET transaction that has been separated from other NET transactions due to its uniqueness and specific audience. The Borrowing from Treasury application provides an on-line process for creating, approving and reviewing Borrowings from Treasury.

The Appropriation Warrant application provides automated processing and display of Appropriation Warrant transactions. It eliminates manual processing of TFS 6200, 6201, 6202, and 6203. It automates any necessary approvals or certifications.

It provides the capability for the Budget Reports Division to electronically create Warrant transactions for each Federal Program Agency (FPA) based on a U.S. Code, Statue, or Public Law. FPAs can view approved warrants based on their user profiles.

The Warrant Journal Vouchers (WJV) application provides automated processing and display of the Journal Voucher transactions. It eliminates manual processing of the OF 1017-G. It also automates any necessary approvals or certifications. It provides the capability for the Budget Reports Division (BRD) to electronically create WJV transactions for each agency based on a U.S. Code, Statute, or Public Law. FPAs can view approved WJV based on their user profiles.

The Borrowing from Treasury, Non-Expenditure Transfers, and Warrant Journal Voucher applications were programmed using Active Server Pages (ASP) and Visual Basic on a Structured Query Language (SQL) server database at the former Bureau of the Public Debt.

All GWA applications now reside on a Federal Reserve Bank server called the Treasury Web Application Infrastructure (TWAI) and are written in Oracle.

Because of these changes, you won't need to maintain two separate IDs and passwords to access your GWA information.

The GWA Security and Administration Module features a new self-enrollment process. You have a new URL, user id, and password to use with ATM.

The redesign of the applications includes the same functionality as the first release, but it has a new look, feel, and navigation. The second build of ATM includes the first release of the Appropriation Warrants application.

Microsoft Internet Explorer (Version 6.0 or above)

You may request access to ATM by visiting the GWA Website and clicking on Enrollment. GWA System users will be required to select the enrollment option and have their request routed to their supervisor for approval. Please note that employees will not be able to enroll or make modifications to their access unless their supervisor is already enrolled.

The CTA component is a system used by Federal Program Agencies to report their monthly accounting activity to Treasury, Bureau of the Fiscal Service (Fiscal Service).

The CTA SF-224 monthly reports transmitted to Treasury are the basis of Treasury's publications to Congress and the public regarding federal revenues and expenditures.

CTA consists of three main sections:

Section 1 Classification and reclassification by Treasury Account Symbol (TAS)

Section 2 Payments and IPAC

Section 3 Collections.

The CTA component provides Federal Program Agencies (FPAs) that utilize Fiscal Service Regional Finance Centers for their disbursing activity the capability to submit their monthly statement of transactions to Fiscal Service.

The CTA component sends data to CAFÉ (Central Accounting Front End) and CAFÉ will then send the data to STAR (Central Accounting System).

The CTA component is comprised of four sections (tabs):

• Section 1: Reclassifications,
• Section 2: Payments,
• Section 3: Collections, and
• Section 4: Balance Indicator.

The preparer is able to enter data into Sections 1, 2 and 3 based on their GWA Reporter status. This will dictate which sections/lines of the Classification Transactions and Accountability component are enabled or disabled. The Balance Indicator section is informational only.

Other functions performed within CTA include:

• the ability to submit supplemental reports,
• system calculated totals and sub-totals,
• scales that display balance conditions,
• reduction of on-line entry by copying repetitive data fields,
• interactive edits,
• availability for historical data available on-line, and
• the ability to process transactions on-line interactively.

All Classification Transactions and Accountability users also have the option to submit their SF-224.

As a Classification Transactions and Accountability users, you have the option to submit your Classification Transactions and Accountability via bulk transfer. You can submit your data using a properly formatted text file.

Bulk file formats can be found under "File Formats" on the Reference and Guidance page.

Microsoft Internet Explorer (Version 6.0 or above)

You may request access to CTA by visiting the Enrollment page or clicking on "Register" located on the GWA system logon page (https://cars.for.fiscal.treasury.gov).

GWA System users will be required to select the enrollment option and have their request routed to their supervisor for approval. Please note that employees will not be able to enroll or make modifications to their access unless their supervisor is already enrolled.

Treasury Service Center Help Desk
877-440-9476

Governmentwide Accounting Customer Relationship Management Division
GWA-CRM@fiscal.treasury.gov