3.17.221. Enterprise Computing Center Data Controls

(1) This IRM includes instructions for:

1. Balancing of ECC weekly Master File processing

2. Balancing of ECC daily and weekly and Individual Master File (IMF) processing

3. Balancing of files received from the Submission Processing Campuses, Bureau of Fiscal Services, Regional Financial Centers and internal processing

4. Preparing and balancing the Reciprocal Accounting Control Report (RACR) if manual intervention is necessary

5. Reconciliation of the Master File - prepare Data Adjustment Vouchers if necessary

6. Balancing of Revenue Receipts received from the Submission Processing Campuses

7. Control of refund data released to Bureau of Fiscal Services (BFS)

(1) Enterprise Computing Center (ECC) control and accountability begins with the acceptance of ECC-Memphis (ECC-MEM) and ECC-Martinsburg (ECC-MTB) Master File data. Such data includes Service Center Control File (SCCF) and Generalized Unpostable Framework (GUF), which are input to the Weekly Submission Processing Campus Reports processing (IMF Weekly receipts and Business Master File (BMF) Weekly Receipts); General Mainline Framework (GMF), End of Day (EOD), and Electronic Federal Tax Payment System (EFTPS), which are input to Joint Processing Data (JPD) processing. (List is not all inclusive.)

1. The initial acceptance of Reports data is acknowledged within 160-02 and 460-02. Acceptance of JPD is acknowledged with Accountability Acceptance Vouchers (AAV) 793-01, 793-02 and 793-04. (The acronym 'AAV' is used to reference any of the following: 793-01, 793-02, and 793-04, MCC SC Trans Release Acceptance Voucher, 793-02, Abridged Acceptance Voucher; 160-02 and 260-02, MCC Automated Balancing Report Abridged Acceptance Voucher.) (See Exhibit 3.17.221-11 and Exhibit 3.17.221-35)

2. In January 2012, IMF generates daily and weekly AAV summaries for the 793-01-11 files. The AAV summaries will reflect data on the input file sent for processing at the Master Files. IMF will generate daily AAVs in the Customer Account Data Engine (CADE) 2 daily processing environment.

3. JPD Router Runs verifies that the data on the media file is acceptable for further ECC Processing.

4. If a service center file is not acceptable, Master File Scheduling at ECC will request a replacement file from the ECC-MEM/ECC-MTB via the Internal Revenue Workflow, Optimization, Requests, and Knowledge System (IRWorks).

(2) The JPD Router Run separates the ECC-MEM/ECC-MTB data into the following files:

• Individual Master File (IMF)

• Business Master File (BMF)

• Employee Plans Master File (EPMF)

• Information Returns Program (IRP)

• Combined Annual Wage Reporting (CAWR)

(3) Each Master file is then processed under separate project programs,

• IPD (IMF daily processing) - project 460

• IPW (IMF weekly processing) - project 460

• BPW (BMF weekly processing) - project 160

• PPW (EPMF weekly processing) - project 130 and 260

• CAWR (BMF weekly processing) - project 402

(4) The Master File Support (MFS) function Computer System Analysts (CSAs) and Resident Programmer Analysts (RPAs) is responsible for ensuring that the totals of records and/or prejournalized debits and credits are balanced inputs to outputs before the initiation of succeeding runs (run-to-run, abends, aborts due to imbalances, programming issues). Also, required balancing of data must be complete and correct before the release of files to the Submission Processing Campuses or Kansas City Financial Center

(5) Reconciliation using Data Adjustment Vouchers (DAV) to request adjustments to the reciprocal controls between ECC and the various campuses is the responsibility of the Processing Validation function. MFS will open a IRWorks ticket to document all processing discrepancies.

(1) References of Submission Processing Campus procedures are found in the following IRMs:

• IRM 3.17.30, Accounting and Data Control, SC Data Controls

• IRM 3.17.63, Redesigned Revenue Accounting Control System

• IRM 3.17.79, Accounting Refund Transactions

• IRM 21.4.1, Refund Research

• IRM 3.17.277, Electronic Payments

• IRM 3.17.64, Accounting Control General Ledger Policies and Procedures

(2) References of Operations Services, Scheduling & Validation Branch procedures are found in the following IRMs:

• IRM 2.7.6, Systems Scheduling

• IRM 2.7.9, Enterprise Computing Center - Martinsburg (ECC-MTB) Processing Timeliness

(1) Automated Data Processing (ADP) Output Controls - Automated balancing routines containing equations to compile data from various locations, including Log Analysis and Reporting System (LARS) controls to summarize an output control for quick reference by PVS; replaces manual compilation of output controls in IBM production.

(2) CADE 2 - Scheduled Schematic to Processing Time Frames Mapping - This spreadsheet is saved on the Service operation Command Center (SOCC) SharePoint and lists all critical jobs that are processed daily and weekly. This report shows the IMF run schematic time frame, where we are in processing, and if any tickets are opened on the jobs, etc. PVS uses this tool to show if IMF cycle has good completion, what jobs are still waiting to process, what jobs are bad and any tickets that are open. This information is utilized to identify current status and to determine if any downstream processes are impacted. Each IBM Master File group has access to update their part of the spreadsheet; PVS updates refund certification, turning it green for all good, red to indicate issue resulting in refunds being suspended.

(3) C - List - Created under an option in LARS. Contains the audit trail of LARS run-to-run balancing of processing in IBM production environment.

(4) Control D - Secured web-based on-line report viewing system. Control D Web can be accessed by using the following link. CONTROL-D/WebAccess Server - LOGIN (irs.gov) Request Type = Login Window

(5) DOC IT - Secured web-based application that stores computer operator handbooks and schematics, database is updated by national office programmers. PVS uses this tool to validate that the jobs are being processed timely and in the correct flow, and no files have been left out of the job stream.

(6) ENDEVOR - Automated Configuration Management Tool - IBM. Use of the ENDEVOR tool ensures that controlled production libraries contain the official version and level, of all existing IRS IBM application source code. ENDEVOR facilitates easy access to the official level of source code as a starting point for development activity, significantly reduces the effort required to transmit software to production sites after development and testing, and ensures that modified source elements do not move into production libraries until the appropriate time.

(7) Intershift Report - Report created by IBM Automation Section and maintained by Master File Scheduling. This report resides on the IBM mainframe. This report provides a synopsis of Master File processing activities. It provides a status of all jobs out on the active job list, what jobs have ran, what conditions the jobs are waiting for to run, and if any IRWorks tickets opened, the number associated with that run. Report is updated at the end of each scheduling shift daily.

(8) Processing Notes - Updated and maintained by IBM Scheduling Section based on information and directions provided by the programmers for establishing the daily/weekly processing schedules. This information is located on the ECC website under system support. PVS uses these notes to verify jobs listed in the Production Log (PLOG) on the mainframe were input accurately for that cycle. Information in the processing notes will indicate if there are any ENDEVOR memos for the cycle that may have transmitted a new Job Control Language (JCL) for processing the job; PVS verifies the correct JCL was used based on the memo.

(9) Resource Access Control Facility (RACF) / IBM Mainframe - A Software Security Package leased from IBM and is installed on the IBM-compatible Master File computers.

(1) The Budget and Accounting Procedures Act of 1950, and amendments thereto, places the responsibility for establishing and maintaining adequate systems of accounting and internal control upon the head of each executive agency. These systems must conform to the accounting principles, standards, and related requirements prescribed by the Comptroller General of the United States. These are reflected in the "General Accountability Office Policy and Procedures Manual for Guidance of Federal Agencies." Section 113 of that act states that the head of each executive agency shall establish and maintain systems of accounting and internal control to provide:

1. Full disclosure of the financial activities of the agency

2. Adequate financial information needed for management purposes of the agency

3. Effective control over and accountability for all funds, property, and other assets for which the agency is responsible, including appropriate internal audit

4. Reliable accounting results to serve as the basis for preparation and support of budget requests for controlling the execution of its budget, and for providing financial information required by the Office of Management and Budget

5. Suitable integration of the accounting of the agency with the accounting of the Treasury Department in connection with the central accounting and reporting responsibilities imposed by the Secretary of the Treasury

(2) The accounting system of an executive agency or any of its component parts is subject to review and approval by the Comptroller General. The continuing efforts to improve, modernize, and simplify accounting systems in the Federal Government are exercised under a "Joint Program" sponsored by the Comptroller General, the Secretary of the Treasury, and the Director of the Bureau of the Budget.

1. This program contemplates the full development of sound accounting within each executive agency, as a working arm of management, and in terms of financial information and control. It envisions an integrated pattern of accounting and financial reporting, for the Government as a whole, that will be responsive to executive and legislative needs.

2. The established accounting and reporting principles, standards, and basic procedures will take into consideration the various areas of responsibility involved, the elimination of overlapping operations and paper work, and the fuller application of efficient methods and techniques in accounting operations throughout the Government.

3. Integration of revenue accounting data with central accounts maintained by the Treasury, Bureau of Fiscal Services is accomplished primarily by the submission of monthly SF 224, Statement of Transactions, reporting deposits, classified collections, and disbursements.

(1) Service officials and managers must communicate security standards contained in IRM 10.2.11, Basic Security Concepts, to subordinate employees and establish methods to enforce them. Employees are responsible for taking required precautions in providing security for the documents, information, and property which they handle in performing official duties.

(2) Security safeguards, adequate security equipment containers, and facilities must be provided for the safeguarding of all protectable items per procedures in IRM 10.2.11, Basic Security Concepts .

(1) The Enterprise Computing Center (ECC) is primarily responsible for maintenance of the Master File Record for each taxpayer and for the electronic processing of inputs and outputs related to the Master File records.

1. ECC will maintain accounting and control data for BMF and IMF, records through systemically posted Master File control records. The manual creation of Control Registers is optional (not required) as the count from the Auto Control Records will be the systemic point of validation for run-to-run balancing. There are no Master File processes dependent upon the manual preparation or balancing of the control register. All financial data for Master Files will be maintained in the Redesigned Revenue Accounting Control System (RRACS). RRACS balancing will be performed by the Submission Processing Campuses.

   Note: Control Registers may be prepared if deemed necessary by Information Technology EOPS PVS management in support of unique processing periods such as start up or special circumstances such as conversion or transition processing.

2. ECC will maintain a Reciprocal Accounting Control Records (RACR) for each Submission Processing Campus. An IMF RACR will be created daily as well as weekly in the CADE 2 environment. (See Exhibit 3.17.221-17)

3. During Master File posting operations at ECC, various files of accounting transactions, adjustments, refund data, and abstracts of revenue receipts will be generated. These output files are transmitted to the appropriate Submission Processing Campuses for printing and for post-journalization through RRACS.

(2) PVS will electronically certify refund schedules, for IMF and BMF, for each Submission Processing Campus. The schedules cover the total count and amount of overpayment, principal, and interest for IMF and BMF refund data.

1. An Authorized Certifying Officer of ECC will certify each voucher for the account of the applicable Submission Processing Campus Director.

2. The electronically certified vouchers and the refund media will be transmitted to the Kansas City Financial Center for issuance of the refund checks and direct deposit. (See IRM 3.17.79.6.4, Bureau of Fiscal Services Secure Payment System)

(1) IBM Service Center Input Processing Automation System (SCIPAS) Scheduling is responsible for the following:

1. Building schedule for IBM Master File processing

2. Compiling processing notes using COHs, transmittal notes when changes are made, and e-mail from programmers, and post to the shared drive

3. Build reject files based on transmittals received from program areas

4. Resolving flags issued by SCIPAS

5. Release refund files for transmission to BFS

(1) The IBM CSA Section is responsible for the following:

1. Monitoring IBM Master File processing using COHs, programming notes

2. Resolving LARS Out of Balances (LOOBs) - coordination with IBM Scheduling and programmers

3. Resolving abends and aborts – coordination with programmers

4. Initiating and updating IRWorks

5. Referring unresolved issues to RPAs and programmers

6. Validating RECAP/REC are in balance (Initiate actions to research and resolve any out of balances as they occur)

7. Communicating release of refund files to IBM Scheduling

(1) The Processing Validation Section (PVS) coordinates with Submission Processing Campuses regarding reciprocal Master File accounts and balances, advises on adjustments, balances and certifies refunds, applies control systems to assess the validity and propriety of operational processes and to detect data or systemic irregularities, initiates investigative and diagnostic action to resolve problems, reports on accountability impact and maintains audit trails when it is necessary to manually create the audit trail, coordinates analysis of error-file data, provides adjustments (DAV's) to the Submission Processing Campuses and validates quantitative and monetary controls for all Master File production processing when manual processes are required.

(2) PVS is responsible for the following:

1. Refund validation and certification (Interface – IBM Master File and BFS) Priority

2. Data Adjustment Voucher (DAV) preparation and distribution (IBM Master File and Submission Processing Campus Accounting)

3. Documentation of all activities in the remarks section of the Reconciliation to explain out of balances and actions taken to resolve

4. Validation of all Master File output (Interface – IBM Scheduling, CSA Staff, Programmers)

   Note: “v” to validate jobs – looking for indication of an unresolved error on the control list (out of balance indicated to the right of each job)

5. Validate daily Revenue Receipt output controls (Interface - IBM Master File and Submission Processing Campus Accounting and Unisys Mainline)

6. Verification of RACR summary report submitted by Submission Processing Campus Accounting

7. Supporting Tasks

• Review and analysis of CLIST

• Validation of errors within Master File output controls

• Confirmation all out of balance Joblog Validation listings are resolved and require no further action by PVS.

(3) PVS is responsible for monitoring any out-of-balance datasets.

• Bring up the daily listing of Joblog Validation at Control D

• If LOOB exists in the listing, check for a IRWorks Ticket

• If LOOB is detected, verify the COH and schematic

• If LOOB notate IRWorks ticket number

• Contact Lead and Manager for their approval.

• Lead should check the validation list to see if JRF is present. When completed, the lead will check off the lead portion of the validation listing.

(1) Each Submission Processing Campus is a separate accounting station and is assigned an identifying numerical "Agency Location Code." The Submission Processing Campus Director is accountable for revenue receipts and repayments deposited for application to BMF and IMF accounts, and disbursements made from these accounts.

(2) Each Submission Processing Campus will:

1. Maintain a general ledger and such subsidiary records as are required herein. Reconcile the general ledger accounts and subsidiary records or files daily, weekly, and monthly (RRACS)

2. Control all accounting documents within the Submission Processing Campus area for entry to the BMF and IMF accounts, and for journalizing and posting to the General Ledger

3. Receive or initiate, control, and process all BMF and IMF accounting transactions involving other Submission Processing campuses

4. Receive and control BMF and IMF accounting outputs, and accomplish required journalization and general ledger postings

5. Reconcile the RACR from ECC to the Submission Processing Campus general ledger

(1) IBM Mainframe (SCIPAS) receives the Tape Edit Processing (TEP) Controls from ECC Unisys once the Submission Processing Campus releases the TEP for transmission via Sterling Commerce Connect: Direct MVS, referred to as Network Data Mover (NDM).

(2) GMF1545, SC Trans Release Summaries.

1. Other Total Summary (See Exhibit 3.17.221-1)

2. Grand Total Summary (See Exhibit 3.17.221-36)

3. Summaries for each file containing data (See Exhibit 3.17.221-37)

(3) GMF2545 ELF SC Trans Release Summaries

(4) SCF1340, Revenue Receipts Control Sheets (RRCS), daily and weekly. (See Exhibit 3.17.221-3)

(5) GUF5342, Revenue Receipt Control Sheets—Nullified Unpostables, weekly (Tuesday) (See Exhibit 3.17.221-4)

(6) EFT1545, EFTPS Daily Trans Release Summary (OSPC only)

(7) Other EFTPS reports may be received online.

1. CMS22 - Weekly Trans Release Summary

2. CMS23 - Daily Revenue Receipts Control Sheet (See Exhibit 3.17.221-28 and Exhibit 3.17.221-29)

3. CMS23 - Weekly Revenue Receipts Control Sheet (See Exhibit 3.17.221-28 and Exhibit 3.17.221-29)

Note: The EFTPS Daily Trans Release Summary and Revenue Receipts Control Sheet provide cumulative data should more than one TEP be run for the same date. Reports for the final TEP must be balanced to the sum of the TEP records received for the date.

(8) Tape file GMF1545MCCPR with print capability is retained by the Submission Processing Campus for 30 days and printed upon request or when needed to resolve discrepancies. The print tape is no longer sent to ECC.

(9) All data and control files (i.e., GUF, SCF1340, GMF, EOD, EFTPS, etc.) transmitted via Connect:Direct and magnetic media transmitted daily for the current cycle should be received at ECC no later than 5:00 PM Eastern time each workday.

1. If SCIPAS does not receive a file per the defined schedule, SCIPAS will contact Unisys.

2. Unisys will contact the Submission Processing Campus if data is not received within its expected arrival time.

3. Data received early should be controlled and held for processing in the correct cycle. The Submission Processing Campus should be notified if data for the next cycle (day) was processed early by mistake or if data is regularly received early from the same center, indicating that the center is closing the cycle too early.

(10) Following the end of the fiscal year, Submission Processing Campuses will include additional controls called 13th Month Supplementals with the regular TEP controls.

1. The 13th Month Supplementals are run the first two Submission Processing Campus cycles in October.

2. These controls will include daily and weekly mainline RRCS and weekly unpostable processing. When transmitted the supplementals will be identified by an "s" in the first position of the two digit workgroup.

3. The control dates will be those of the previous fiscal year.

4. The 13th Month Supplemental allows revenue received, but not processed by the end of the fiscal year, to be accumulated for the appropriate year for reports purposes.

(11) Unisys will verify receipt of all TEP controls. If necessary, contact the Submission Processing Campus to retransmit the controls file if the initial transmission is bad. A retransmission controls file can be rerun after the initial transmission is uncataloged.

(1) Every media shipment received by ECC - Unisys should contain summary count and amount information, even for transactions that are not processed by the TEP.

(2) A list of Non-TEP transaction media shipped by the Submission Processing Campus to ECC can be found in IRM 3.30.123, Processing Timeliness: Cycles, Criteria, and Critical Dates.

(3) These media controls will be used for balancing purposes by the Processing Validation Section, when manual balancing is necessary and directed by management.

(1) The JPD Router Runs perform the initial processing and acceptance of Submission Processing Campus data by ECC. Each program sorts Submission Processing Campus data creating separate media files.

1. GMF data is processed in JPD run 793-01. Processing of EFTPS data is done in JPD run 793-04. Deletions can be processed in both the 793-01 and 793-04 runs.

2. IMF EOD data and EFT1601 for IMF are processed in JPD run 793-02.

(2) BMF and EPMF EOD data bypass the router runs and are processed directly to run 160-02.

(3) The JPD and 02 run programs balance input to output control records. A Trans Release Acceptance Voucher (AAV) is generated when the JPD has successfully processed. (The acronym "AAV" is used interchangeably to reference any of the following: 793-01, MCC SC Trans Release Acceptance Voucher; 793-04, MCC Trans Release File Acceptance Voucher; 793-02, Abridged Acceptance Voucher; and 160-02, MCC Automated Balancing Report Abridged Acceptance Voucher.)

1. A generated AAV is indicative of correct data; no further balancing of the input data is required by PVS.

2. An AAV will not generate if an out of balance condition occurs. When the AAV fails to generate, a Priority 1 work stoppage ticket will be issued by Master File Scheduling and assigned to the Master File Section (MFS) with a share to System Automations Branch (SAB). Contact may be needed with Submission Processing Headquarters to reconfirm counts and amounts submitted for transfer in comparison to the JPD report summaries.

(4) After all ECC-MEM/ECC-MTB data is processed for the cycle (daily for IMF), AAV Summaries for each center are generated by cycle (daily IMF) from the JPD 793-1A (793-01 and 793-04), PA and PB (793-02).

1. Processing Validation Section will verify the input of the ECC-MEM/ECC-MTB data transmitted VIA CONNECT:Direct using the AAV Summaries.

2. Input of shipped reels will be verified using the ECC-MEM/ECC-MTB TEP and the LARS validation summary screen. Each input reel should also produce an AAV with the exception of file EPM-02-01 input to 260-02.

3. The IMF daily and weekly and the BMF and EPMF AAV Summaries reside on Control D for Submission Processing Campus viewing and verification of input.

4. ECC suspends copies of the weekly AAV Summaries by Submission Processing Campus and by Master File pending verification and balancing of the monthly reports.

(5) The 793-01-17 Drop File is a print (error listing) and is sent to the Submission Processing Campus with the AAV for all honored deletions.

(1) If a file cannot be processed, it will be flagged by SCIPAS.

1. The SCIPAS Team in Master File Scheduling will investigate. If SCIPAS does not receive a file per the defined schedule, SCIPAS will contact Unisys.

2. The Scheduler in Master File Scheduling may request assistance from the Master Files Automation Section (MFAS) if a replacement is necessary.

3. If a replacement file is needed, Master File Scheduling will prepare a Info Notes. The Info Notes should include the workgroup, file ID, batch and cycle, a precise detailed description of the reason the file was flagged, and the IRWorks ticket number.

4. Master File Scheduling will contact the Centralized Help Desk to initiate a request for a retransmission and furnish the necessary information from the Info Notes.

5. The IRWorks tickets will notify the appropriate site.

6. The Computer Center Journalization System (Info Notes) will be updated with the IRWorks ticket number.

(1) Input, sort, and merge processing reformats, sorts and merges Submission Processing Campus data, Agency and regional financial center data with other ECC files such as the cross-reference file and the resequence file. This process prepares data for posting to the Master File.

(2) The projects for each Master File are:

• 160 for BMF (BPW)

• 460 for IMF (IPD, IPW)

• 130 and 260 for EPMF (PPW)

(3) As these runs are processed, Master File programs contain internal balancing features resulting in the generation of controls and LARS counters are generated for balancing purposes. The controls and LARS counters are systemically compared with the input record totals in order to verify the operational validity of the output. LARS counters are the recognized General Accountability Office (GAO) audit trail used to validate run-to-run balancing. This audit information includes all input and output records and prejournalized debits and credits.

1. If manual balancing is necessary and directed by management, the Processing Validation computer assistant should refer to the project Computer Operator Handbook (COH) for specific balancing requirements.

2. If IT management determines Controls Registers are necessary for audit trail purposes, error or reject records and money amounts will need to be posted on the Controls Register for complete and correct balancing of the processing run.

(1) The beginning program for Master File projects is the 02 run. This run reformats data for Submission Processing Campus, ECC, and other files in preparation for subsequent processing.

(2) Master File will systemically balance the 02 runs and ensure the total input transactions equal the "Total Output Transactions Controls." When the input processing run has been balanced, the transaction output will be systemically input to the sort run.

(3) The remaining paragraphs in this section only apply if manual intervention is necessary and directed by management. To balance the 02 run, list on the Controls Register all input files to the run. (See Exhibit 3.17.221-5 and Exhibit 3.17.221-6)

1. Inputs will include 793-01, 793-04, 793-02, resequence file, undelivered/cancelled refunds, cross-reference file and other files depending on need and availability.

2. CAWR (when available) is included on BMF.

3. Undelivered/cancelled refund Data is input to run 160-08 for BMF processing.

(4) Carefully review the Log Analysis and Reporting System (LARS) validation summary to determine the files input. Because of computer scheduling and constraints, there are several passes of the 02 run which will need to be summarized through the Statistical Analysis System (SAS) controls and manual postings to determine the total input records and prejournalized debits and credits. (See Exhibit 3.17.221-7)

(5) Record the total input records and prejournalized money amounts on the Controls Register.

(6) Record any reject or error records and money on the Controls Register to ensure accountability. Initiate IRWorks, listing the reject and route to the Master File Scheduling (MFS) staff for disposition.

(1) The next step of 02 processing sorts the records to various categories for posting to the Master File.

(2) The sort data will contain the input from the 02 run, zip code transactions, and other miscellaneous data.

1. The sort control consists of total records, including prejournalized debits and credits that will be reflected in the output controls.

2. Output control totals will be verified with the total of the transactions input.

(3) When the sort processing run has been balanced by internal Master File balancing, the transaction output is input to the merge run.

(4) If manual intervention is necessary and directed by management, continue using the Controls Register for the processing cycle. (See Exhibit 3.17.221-5 and Exhibit 3.17.221-6)

(1) The next step of 02 processing is merging all files for the cycle. IMF will perform this activity daily in daily processing. BMF and EPMF will perform this weekly.

(2) If manual intervention is necessary and directed by management, continue using the Controls Register for the processing cycle.

1. Post and summarize all input files records.

2. Balance using the input from the sort runs, plus additional input files, to verify the total output records, debits, and credits.

(3) Discrepancies should be reported by opening a IRWorks ticket. Annotate the ticket number on the Controls Register.

(1) PVS serves as a liaison between Master File Section and the Submission Processing Campuses to assist in resolving imbalance conditions. PVS is responsible for issuing Data Adjustment Vouchers as necessary when transactional records have to be deleted from Master File processing. See IRM 3.17.221.7, ECC Control Adjustments.

(2) The IRWorks ticket is initiated by PVS Computer Assistant via e-mail to Lead Computer Assistant to record, control, resolve errors, and to provide an audit trail for all unexplained discrepancies.

(3) After consulting with the Lead Computer Assistant or management, the Computer Assistant opens the IRWorks ticket for all error records, run imbalances, dropped input reels, and controls irregularities.

(4) Identify the cycle and run designation and provide a brief but inclusive description of the problem. For run imbalances, provide the record counts and money amounts; error record information can be reviewed on-line by accessing Control D.

(5) Based upon the Lead Computer Assistant's direction, the ECC Help Desk will forward the IRWorks ticket to the appropriate area for resolution and response.

(6) When the IRWorks response is returned with an acceptable resolution, determine whether an adjustment action or additional data should be provided.

(7) Record follow-up action taken on the completed IRWorks. Annotate the Control Register report page with the IRWorks ticket number for an audit trail of the discrepancy to resolution.

(1) After resolution of certain processing discrepancies by response to IRWorks from the MFS staff, the PVS lead will access an online menu screen to prepare the Data Adjustment Voucher (DAV), Form M-4496A. The DAV is used to record reciprocal accounting control balance between ECC and the Submission Processing Campuses. The DAV is prepared as deletions are reported by the Master File program area and should be issued within one workday of identification. (See Exhibit 3.17.221-8)

(2) The DAV is used to control the required adjustments, to notify the affected Submission Processing Campus of the problem, and to provide the information needed to correct the out of balance condition.

(3) The DAV should provide all information available and necessary for the Submission Processing Campus to make the appropriate adjustment on a timely basis. This information is available on the 460-02-16.

(4) The minimum information provided on the DAV should include the following when applicable:

• Taxpayer Identification Number (TIN)

• Document Location Number (DLN)

• Amount (Debit or Credit)

• Processing Cycle

• Reason for the adjustment

• Copy of Error/Reject List, run 460-02-16, should be sent to the campus electronically via secure e-mail, if too large to input on Form M-4496A

• Any other pertinent documentation

• Line Code if related to the SC Recap of Assessments, Abatements, and other Post Journalized Transactions

• Explanation including what the amount should have been and the amount that actually posted on the SC Recap

• Action taken by ECC

• Recommended action to be taken by SPC

(5) The DAV will be loaded to Control D upon completion for each SPC. Notify campuses via e-mail when a DAV has been created.

(6) Any necessary clarification of the DAV should be resolved through telephone contact with the Submission Processing Campus, followed up by an amended DAV if appropriate.

(1) During production processing, transactions may not be processed because of a processing discrepancy or a control irregularity.

(2) These error or reject transactions are dropped from processing and will create an Error or Reject file listing.

(3) Whenever a record opens the error or reject file, the record count and money amount, if applicable, will be displayed in a LARS counter for that run and/or indicated on the Controls Listing when manual intervention is necessary and directed by management.

(4) When manual intervention is necessary and directed by management, the Error or Reject record will need to be listed on the Controls Register to reconcile the input/output totals.

(5) The MFS staff will initiate a IRWorks to the programmer with an explanation of the problem.

(6) Processing Validation will:

1. Prepare DAV if the error or reject necessitates an adjustment action or if the record is to be returned to the Submission Processing Campus for corrective action.

2. If the DAV contains money, the DAV should be processed in the next running of the RACR for input into the Reconciliation in the subsequent cycle.

3. Document DAV information in the remarks section of the RACR.

4. The DAV will be loaded on Control-D for the appropriate Submission Processing Campus.

(1) The IMF DAV is numbered to control, classify, and provide an audit trail if research is needed. These numbers are automatically assigned VIA the on—line DAV program.

1. Position 1 -Type of adjustment transactions, rejected (R), error (E), and blank for all other transactions.

2. Position 2 - File source I-IMF, B-BMF, E-EPMF

3. Positions 3 - 9 - Processing cycle (YYYYJJJ)

4. Positions 10 - 11 - Submission Processing Campus code

5. Positions 12 - 13 - Voucher serial number (sequenced from January 1 to December 31 by Submission Processing Campus, type, and file)

(1) The automated RACR is the cumulative accounting record maintained by ECC for each Submission Processing Campus. (See Exhibit 3.17.221-17)

1. The RACR reflects the monetary value of data input and generated to each Master File (IMF and BMF).

2. The RACR is prepared daily by ECC for each Submission Processing Campus for IMF. The RACR is also prepared weekly by ECC for each SPC for BMF.

3. The RACR should be prepared as soon as all related processing is completed (i.e., unpostables, accounts register, AAV summaries, resequence, cancelled/undeliverable refunds, etc.).

4. At the close of the cycle (may be other than Wednesday if a holiday is involved), there will be one Recap and RACR, which will be tagged with a "H", indicating the last daily which includes the weekly transactions.

(2) The monthly closing of the RACR is made at the end of the last posting cycle for that month. RACRs are programmed to print "Last entry for the Month of" message on the last cycle of the month.

1. This is the last weekly posting cycle of the month for BMF processing.

2. For IMF, this would be the final daily RACR, which will also contain the activity for the weekly transactions.

(3) The monthly RACR is used by the Submission Processing Campuses to reconcile their general ledger control accounts.

(4) Items posted to the RACR are the same items that have been journalized to the Submission Processing Campus general ledger accounts.

(5) ECC has developed ADP programs which assist in preparation of the RACR. Refer to local Statistical Analysis System (SAS) procedures in using these programs.

(6) A copy of each daily and weekly RACR is available to the SPCs via Control D. PVS will no longer forward copies of these reports to the SPCs.

(7) Copies of the RACR are filed separately for each Submission Processing Campus in chronological sequence along with the associated AAVs for those cycles.

(1) The Form 5199A, Reciprocal Accounting Control Record, is automatically generated after the related runs have processed.

(2) The automated Statistical Analysis System (SAS) program supplies the following data extracted from the appropriate controls.

1. The prior ending RACR balance for each Submission Processing Campus and Master File (IMF daily - BMF weekly)

2. The total debits and credits for the cycle from the Accountability Acceptance Voucher Summary, 793-01 and 793-04

3. The total debits and credits for Unpostable transactions from the 60 run (reverse)

4. The total run 43 Accounts Register Non-Prejournalized (NPJ) debits and credits

5. For 160-43 (BMF) the Non-Prejournalized (NPJ) amount is posted less refunds generated.

6. For 460-43 (IMF) the NPJ amount is posted less refunds generated and DMF.

7. The total refund amounts from 160/460-43 (IMF and BMF only)

8. The Criminal Investigation Division (CID) cancelled EFT refund amounts from the 460-38 run (IMF only)

9. DMF Offsets and DMF Reversal transaction amounts from the 460-43 runs (IMF only)

10. Accounts To and From Other Submission Processing Centers amounts from the 43 runs

11. Credits To and From Other Submission Processing Centers amounts from the 43 runs

(3) The total credit amount of cancelled/undelivered refunds from the following schedules:

• SF 1098, Schedule of cancelled Checks

• SF 1185, Schedule of Unavailable Check Cancellation Credits

• EFT 145, Schedule of cancelled EFT items (IMF only)

• Limited Payability

• Reclamation Credits

• Unavailable Check Cancellations (Paper SF 1184)

(4) DAV figures are extracted from the automated DAV program.

(5) The total debit amount for Payment over Cancellation

(1) Form 5198A, Reconciliation of Master File Balance, commonly called the "REC" is generated after the related processing runs completed and the RACRs have automatically processed. This is completely automated and processes immediately after the needed runs have processed. Reconciliation of IMF is daily, BMF is weekly. (See Exhibit 3.17.221-18)

(2) In the event of reruns or other factors that would require a rerun of the RACRs and REC, PVS must first balance the related runs and open a IRWorks to the ECC/MFS requesting a rerun of the RACRs and REC for that cycle. PVS is no longer able to manually submit reruns of RACRs and REC.

(3) The "REC" is used to reconcile the updated Master File balances to the current cumulative net balance on the RACR.

(4) During IMF and BMF conversion processing, Form 5198A, is systemically generated, to reconcile these Master Files separately. (See Exhibit 3.17.221-19)

(1) When a manual creation of the REC is needed, enter the following information:

1. Enter the net balance from the RACRs for each Submission Processing Campus.

2. Enter the cancelled refund amount of CID Transaction Code 841(s) In Records from the 460-37-14 controls to the Transactions Pending Column (IMF only).

3. Account for any adjustments reflected in the "Adjustments in Process" column which are imbalances between the Net RACR amounts and the sum of Transactions Pending (IMF only), Resequenced Pre-Journalized (PJ)Transactions, and the Accounts Register OMB data by Submission Processing Campus.

4. Enter the resequenced PJ Amounts from the Merge Master File Accounts Control, 63 run. (See Exhibit 3.17.221-20)

5. Enter the Accounts Register, SC Recap (43 run) Outstanding Module Balances (OMB) net credits and debits balances. (See Exhibit 3.17.221-21)

(2) The Master File Balance of the "REC" is a summation of the processing segments and the "Resequenced Tax Modules", which must balance with accounts register, OMB Data, net balance.

1. Enter for each segment, from the run 15 controls, the ending entity and ending total tax module balance. (See Exhibit 3.17.221-22)

2. BMF will include segments 1 through 4.

3. IMF will include segments 1 through 6.

4. Enter the net "resequenced tax module" amount from the "Recap of all segments" 15 run processing controls data. (See Exhibit 3.17.221-22)

(3) Complete the preparation of the "REC" by totaling all parts.

(1) The REC is reviewed by the CSA Section immediately following generation of the report controls which are output following successful completion of IMF and BMF determined at the time the RECAP is output. The total of the column labeled “adjustments in progress” should be zero and is verified by the CSA area. There may be counts present in this column by site which indicates a transactional amount is being transferred from one Submission processing Campus to another (TOS and FOS). The CSA notifies IBM Scheduling via IRWorks and Scheduling releases the refund files to BFS to generate control numbers for pre-edit. ECS38 and 39 files for IMF and an ECS41 file for BMF are created after the processing has completed and refund data files have been sent to BFS by scheduling section. There is an agreement that BFS will not issue refunds on the files until the certification files have been received. Automation creates the ECS certification files to transmit to BFS from the following pre-edit files:

1. PDIPW.CFMSPE.F001* (for the 460-39-22 control – paper refunds - IMF)

2. PDIPW.CFMSPE.F002* (for the 460-38-15 control – EFT refunds - IMF)

3. PDBPW.CFMSPE.F001* (for the 160-41-017 control – paper refunds - BMF)

4. PDBPW.CFMSPE.F002* (for the 160-41-017 control – EFT refunds - BMF)

(2) The REC is used to reconcile the updated Master File balance to the current cumulative net balances on the RACRs'.

1. The Accounts Register OMB (160-43, 460-43) total should equal the Master File Balance total. (Net tax module ending balance plus the net resequenced tax module 160-15 or 460-15.)

2. The Reciprocal Accounting Control Column should equal the sum of Transactions Pending (IMF only), Resequenced PJ Transactions, and Accounts Register OMB Data. Any imbalance should be listed under adjustment column.

(3) If an imbalance occurs, the CSA will verify source data, transcription amounts and computation of totals. Report any imbalance for error resolution to PVS for preparation of the Data Adjustment Voucher (DAV).

(4) In the Remarks section explain all items listed under Adjustment in Process Column and comment on actions being taken to resolve imbalances. Include original cycle ID of first occurrence.

(5) If the imbalance cannot be resolved, a Priority 1 ticket will be issued by the Master File Section (CSA/RPA) to the programmer. IRWorks ticket priorities are listed below:

(1) An important and sensitive area of Master File processing concerns the issuance of BMF and IMF tax refunds, and should be considered a priority.

1. Delays or errors in the issuance of refunds could result in large interest payments as well as significant taxpayer relations problems.

2. It is important that problems in the issuance of refunds be identified and resolved at the earliest possible time.

(2) If a file cannot be processed, it will be flagged by Service Center Input Processing Automation System (SCIPAS).

1. The SCIPAS Team in Master File Scheduling will investigate.

2. The Scheduler in Master File Scheduling may request assistance from the Master Files Automation Section (MFAS) if a replacement is necessary.

3. If a replacement file is needed, Master File Scheduling will prepare a Info Notes. The Info Notes should include the workgroup, file ID, batch and cycle, a precise detailed description of the reason the file was flagged, and the IRWorks ticket number.

4. Master File Scheduling will contact the Centralized Help Desk to initiate a request for a retransmission and furnish the necessary information from the Info Notes.

5. The IRWorks tickets will notify the appropriate site.

6. The Computer Center Journalization System (Info Notes) will be updated with the IRWorks ticket number.

(3) All refunds are paid by check or by electronic fund transfer by BFS.

(4) Refunds generated at ECC by weekly Master File and daily IMF processing are transmitted electronically via CONNECT:Direct to BFS.

1. IMF/BMF regular refunds are transmitted via CONNECT:Direct upon completion of refund cycle processing.

2. Notify Chief, OSSVB by e-mail.

3. IMF/BMF EFT refund data is transmitted via CONNECT:Direct upon completion of EFT refund cycle processing.

(1) All refund documents and controls must be reviewed and balanced for completeness and correctness before submitting to Secure Payment System. Balance the refund data to the Master File (460-15 IMF and 160-15 BMF) and to the "Refund Generated" amount on the SC Recap of Assessments, Abatements, and Other Post-Journalized Transactions (460-43 or 160-43).

(1) Some refund cases may be directed to the Error File during processing and will require research to determine validity for further processing.

1. Initiate a File Search Request, Form 9633. (See Exhibit 3.17.221-25)

2. Prepare a PRIORITY IRWorks for MFS staff review.

3. The MFS staff will review and analyze the documentation to determine validity of the refund.

(2) Refunds determined to be valid will be processed as manual refunds by ECC.

1. Prepare a separate Secure Payment System Schedule and route to the assigned Submission Processing Campus.

2. Prepare a DAV advising appropriate Submission Processing Campus of any necessary RRACS journalization or adjustments to the Net Tax Refund Report.

(3) A follow-up telephone contact will be made in twenty-four hours to insure the processing of the manual refunds by BFS.

(4) If the refund is invalid, prepare a DAV requesting that the responsible Submission Processing Campus correct the transaction and complete the necessary journalization.

(1) Department of Treasury requires separate reporting of IMF and BMF refund data, daily for IMF and weekly for BMF. Exceptions would be holidays and elongated processing. This reporting to the Federal Reserve Bank is to insure that funds are deposited into the account for issuance to the taxpayer.

(2) The Processing Validation section will transmit the estimated IMF and BMF Refund Reports, Form MCC-388 to the Department of the Treasury, Secretary Office of Cash and Debt, via e-mail to: Receipts@do.treas.gov, include the Leads and manager on the e-mail. If unable to e-mail, fax to (202) 622-1822. The contact's telephone number is (202) 622-1817. (See Exhibit 3.17.221-26)

1. BMF Refund Report is e-mailed weekly on Tuesday, by 11:00 AM.

2. The estimated IMF Refund Report is to be e-mailed daily by 8:30 AM.

3. If during the cycle a rerun occurs, Treasury will be notified by 8:30 AM that the estimated Refund Report will be transmitted when the rerun has been completed.

(3) The Secretary Office of Cash and Debt will in turn acknowledge receipt of the Refund Report by signing, dating, and faxing acknowledgment back to ECC.

(4) The Refund Report consists of the following data:

1. Count and amount of IMF/BMF refunds by principal, interest and total.

2. Date refunds are to be paid.

3. The count, principal, interest, and total of civil penalties. (IMF only)

4. Cumulative count, principal, interest, and total for IMF refunds and civil penalties.

5. The Debtor Master File (DMF) offsets and reversals by items and amounts.

6. Items, principal, interest, total, and to be paid date for EFT refunds.

7. During BMF accelerated cycles, amounts will be posted for items, principal, interest, totals and "to be paid" date.

(1) ECC Master File Scheduling help desk will contact Kansas City Financial Center (KCFC) when a refund cancellation file is flagged (dropped).

(2) The following information will be provided to KCFC or BFS for replacement media.

1. File ID

2. Batch

3. Cycle

4. Workgroup

(1) Security over disbursement of federal funds is a responsibility shared by Federal agencies and the Treasury Department, primarily through the Financial Center to which payment documents are submitted. Upon receipt of a payment document by a financial center, the first and primary process in examination is the matching and comparison of the electronic signature of the certifying officer to the signature on the Bureau of Fiscal Services (BFS) Form 210, Designation of Certifying Officer.

(2) Kansas City Financial Center requires the following forms to be prepared for the following Secure Payment System (SPS) personnel: (See Exhibit 3.17.221-30 to Exhibit 3.17.221-34)

• Head of Agency (self-appointed) — Delegation of Authority, BFS Form 2958

• Certifying Officer — Designation For Certifying Officer, BFS Form 210

• A Local Service PKI Certificate Action Request is needed for both the COs and DEOs

• Data Entry Operator — Designation For SPS Data Entry Operator, BFS Form 210

Note: Form 210 for Data Entry Operators and Certifying Officers must reference a 310 RFC for Kansas City certification files.

(3) Forward the completed forms to the Enterprise Computer Center (ECC) Staff Assistants Office for the Director's signature. (The Director of ECC has delegation of Authority) This office will send the completed forms to:

Kansas City Financial Center

4241 NE 34th St.

Kansas City, MO 64117

(4) Expiration periods will be calculated based on effective date and will be effective for a full expiration period (as applicable).

• Delegation of Authority - 2 years

• Certifying Officer - 2 years

• SPS Data Entry Operator - 2 years

(5) Confirmation of acceptance of all delegations and designations will be sent from BFS.

(6) Delegators/designators will receive automatic written notifications two months prior to the expiration of all delegations/designations, as well as automatic written notification of the expiration of delegations/designations not renewed.

(7) When the completed forms are returned, copies of all signed forms are filed in the Internet Trusted Registration Agent (ITRA) folder maintained in PVS.

(1) Requesting a new TRA:

1. Complete Public Key Infrastructure (PKI) Support Nomination form, which is available at https://www.fiscal.treasury.gov This form must be completed by the Head of Agency (HOA) or Fiscal Sponsoring Authority (FSA) at the agency. See IRM 3.17.221.10.7 (5) for instructions on completing this form.

2. Complete the PKI Certificate Action Request (CAR) form, which is available at https://www.fiscal.treasury.gov. Select “New Subscriber” in Block 1. This form must be completed by the HOA or FSA at the agency. See IRM 3.17.221.10.7 (6) for instructions on completing this form.

3. Submit paperwork to servicing RFC.

4. Servicing RFC submits paperwork to BFS Headquarters

5. After paperwork has been processed, Existing TRA will receive authorization codes via pinmailer, original CAR, Non-Disclosure agreement and Help Desk Registration Form from BFS; User will receive reference number via e-mail.

6. Existing TRA will complete the In Person Proofing Process which includes:
   1. completing the PKI in Person Proofing Form, which is available at https://www.fiscal.treasury.gov See IRM 3.17.221.10.7 (7) for instructions on completing this form.
   2. having user read the PKI subscriber agreement, which is available at https://www.fiscal.treasury.gov
   3. getting a copy of the users id
   4. having user complete the Nondisclosure Agreement
   5. having user complete the Help Desk registration form

7. Existing TRA will "Create Credential" in ITRA.

8. Existing TRA will submit all paperwork (support nomination form, original certification action request, in person proofing form, non-disclosure agreement, help desk registration form, and copy of id) back to servicing RFC.

(2) Requesting a new SPS User:

1. Complete the PKI Certificate Action Request (CAR) form, which is available at https://www.fiscal.treasury.gov Select "New Subscriber" in Block 1. This form must be completed by the HOA or FSA at the agency. See IRM 3.17.221.10.7 (6) for instructions on completing this form.

2. Submit paperwork to servicing RFC.

3. Servicing RFC submits paperwork to BFS Headquarters.

4. After paperwork has been processed, Existing TRA will receive authorization codes via pinmailer, original CAR, Non-Disclosure agreement and Help Desk Registration Form from BFS; User will receive reference number via e-mail.

5. Existing TRA will complete the In Person Proofing Process which includes:
   1. completing the PKI In Person Proofing form, which is available at https://www.fiscal.treasury.gov See IRM 3.17.221.10.7 (7) for instructions on completing this form.
   2. having user read the PKI subscriber agreement
   3. having user read and sign the SPS Rules of Behavior Form, which is available at https://www.fiscal.treasury.gov
   4. getting a copy of the users id
   5. having user complete the Non-Disclosure Agreement
   6. having user complete the Help Desk Registration form

6. Existing TRA will "Create Credential" in ITRA.

7. Existing TRA will submit all paperwork (support nomination form, original certification action request, in person proofing form, non-disclosure agreement, help desk registration form, SPS Rules of Behavior, and copy of id) back to servicing RFC.

(3) Requesting a Key Recovery:

1. Contact your servicing RFC to advise them that you have a user who has lost their IKey, forgotten their password, changed their name, etc.

   Note: for a user who has changed their name, a new Form 210 will be required with their new signature.

2. Complete the PKI Certificate Action Request form, which is available athttps://www.fiscal.treasury.gov. Select “Recover PKI Certificate” in Block 1 and select the appropriate reason. If reason is not listed, please select “other” and provide a description. This form can be completed by the TRA for key recoveries. See IRM 3.17.221.10.7 (6) for instructions on completing this form.

3. Fax paperwork to servicing RFC.

4. Servicing RFC submits paperwork to BFS Headquarters.

5. After paperwork has been processed, Existing TRA will receive authorization codes via pinmailer , e-mail, or phone call - depending on the urgency. User will receive reference number via e-mail.

6. Existing TRA will complete the In Person Proofing Process which includes:
   1. completing the PKI In Person Proofing form, which is available athttps://www.fiscal.treasury.gov See IRM 3.17.221.10.7 (7) for instructions on completing this form.
   2. having user read the PKI subscriber agreement
   3. getting a copy of the users id

   Note: User should not have to complete another Non-Disclosure Agreement or Help Desk form because the original should already be on file; however, if they choose to complete one, it will replace the one on file.

7. Existing TRA will "Recover Credential" in ITRA.

8. Existing TRA will submit all paperwork (original certification action request, in person proofing form, non-disclosure agreement, help desk registration form, and copy of id) back to servicing RFC.

(4) Requesting to Revoke SPS Users:

1. Contact your servicing RFC to advise them that you have a user who has retired, gotten another job or will no longer be using SPS.

2. Complete the PKI Certificate Action Request form, which is available at https://www.fiscal.treasury.gov select “Revoke PKI Certificate” in Block 1. This form can be completed by the TRA for revokes. See IRM 3.17.221.10.7 (6) for instructions on completing this form.

3. Submit paperwork to servicing RFC.

4. Complete appropriate Form 210 (210 or 210 DEO) to revoke user and submit it to Kansas City Financial Center (KCFC).

5. Servicing RFC will notify the TRA when the Revocation has been completed.

(5) Instructions for completing Fiscal Service PKI Nomination Form:

1. You will need a Fiscal Service PKI Support Nomination form for each TRA and FSA. They must be accurate and all boxes completed except Block 4.

2. Block 1: Check the FSA box for FSAs and the TRA box for TRAs.

3. Block 2: Enter the FSA or the TRA's information in Block 2. The Business Systems Requiring Nomination: SPS FPA ID = CPS1 The Nominee must sign and date the form in this block.

4. Block 3: The Nominating Official must complete this block and sign and date it. The Nominating Official will be a HOA or a FSA. The HOA nominates the FSA and/or the TRAs. If you have a FSA, the FSA can nominate the TRAs, COs, and DEOs.

5. Block 4: Leave blank.

(6) Instructions for completing PKI Certificate Action Request Forms:

1. For the nominations, you must have a PKI Certificate Action Request (CAR) for each DEO, CO and TRA.

2. Block 1: Check 'New Subscriber'; check 'Enterprise Certificate' and 'Medium' as the Level of Assurance. The Business System Requiring Certificate: SPS Other Information: FPA ID = (YOUR FPA ID) and Role of User (CO, DEO or TRA)

3. Block 2: Enter the DEO's, CO's, or TRA's full name, the organization name and address, the correct e-mail address, phone and fax number of the person.

4. Block 3: The FSA or HOA nominates the DEOs, COs, and TRAs. His/her data is to be entered in Block 3.

5. Block 4: Enter the information of the TRA that will be receiving the Authorization Code. First time should be the TRA at the RFC. After the SPS site visit, the agency’s TRA information will be entered on any subsequent forms submitted.

(7) Instructions for completing PKI Certificate In-Person Proofing Forms:

1. You must complete a PKI Certificate In-Person Proofing Form (IPP) for each DEO and each CO and each TRA that is created OR recovered.

2. Block 5: Enter the DEO's, CO's, or TRA's full name, the organization name and address, the correct e-mail address.

3. Block 6: Enter the DEO's, CO's, or TRA's Government-issued photo ID for identity authentication in the space provided. Acceptable forms of identification are: State Driver’s License, Military ID, U.S. Passport or U.S. Government Work ID. If the request is approved, check the “approved” box. If the user provides ID that is not in agreement with the PKI form (name changed) or has expired, check the “rejected” box and provide the reason. If request is rejected contact your servicing RFC for further instructions. Indicate whether the User is an Employee or Contractor by checking the appropriate box.

   Note: Remember to make a copy of the ID (front and back) for the servicing RFCs files.

4. Block 7: Subscriber (DEO, CO, or TRA) must sign, date and put the time in this block.

5. Block 8: Enter the information of the TRA that performed the IPP. Please remember to indicate whether the User is an Employee or Contractor by checking the appropriate box.

(1) The Master File Report of U.S. Internal Revenue Receipts generated monthly is balanced to a worksheet with cumulative revenue receipts data. The data for the area offices is furnished to each Submission Processing Campus via Control D. (180-40-011 for BMF and 480-55-011 for IMF)

(2) Revenue receipts are defined as any current prejournalized input amounts with a valid document code except 45, 48, 51, 58 or 34 and with a current fiscal year DLN control date. (See Exhibit 3.17.221-10)

1. The report period begins October 1 each fiscal year and is cumulative through September 30.

2. Revenue receipts reported are selected by DLN control date, which is the date of deposit or reclassification.

3. Revenue receipt Document Locator Numbers (DLN) with control dates before the report period (October 1) are not accumulated for report purposes.

4. Revenue with control dates from October 1 to the end of the current Report month are accumulated as "current." Revenues with control dates following the end of the current month report are accumulated as "future."

5. During special 13th Month Supplemental processing (first two cycles in fiscal year for Submission Processing Campuses), revenue receipts will accumulate as current for the previous fiscal year for report purposes. Submission Processing Campuses will furnish special 13th Month RRCS in addition to the regular paperwork.

(3) The report month cutoff is determined by the S107 Date. In the 460-02, the S107 date determines whether a receipt is to be classified as current or future money. The S107 date is the Julian Date of the last day of the month. The S107 cycle is the campus production cycle that contains the last campus production date of the month in accordance with the cutoff cycles listed in IRM 3.17.30.14.1.1, Accounting and Data Control, SC Data Controls, Reports Cycle Cutoff Dates.

(4) The report month cutoff (see cycle cutoff chart in IRM 3.17.30.14.1.1) is determined by the last day of the month as it falls in the last campus production cycle of the month. Beginning in processing year 2012, the GMF campus production cycle starts on a Thursday and ends on a Wednesday with the final transfer of Tape Edit Processor (TEP) data to Master File on Thursday. If a holiday falls on a Thursday during the last cycle, the final transfer day will be Wednesday.

(5) For Supplemental processing at the end of the fiscal year, two cycles of inputs to the 460-02 are run manually with the S107 card and the Computer Paragraph (CP) 23 card reflecting the last reports cycle of the year. This is done in order to pick up money for the report and place in the correct category, current or future. See Reports Cycle Cutoff Date Chart in IRM 3.17.30.14.1.1, Reports Cycle Cutoff Chart.

(6) Revenue receipts controls received on-line from the Submission Processing campuses include:

• Revenue Receipts Control Sheet, (RRCS) (SCF1340)

• Nullified Unpostables RRCS (GUF5342)

• EFTPS (CMS2340) - Ogden Only

(1) To ensure that revenue receipts retain the balances accepted from the Submission Processing Campuses, ECC will monitor the flow of revenue data through the Automated Data Processing (ADP) system from receipt of Submission Processing Campus TEP transactions through the Revenue Receipts Control Sheet, 180-35 (BMF), 480-35 (IMF), for each cycle. Any imbalance or processing discrepancy will be reported using IRWorks.

(2) Automated Data Processing (ADP) system performs a balancing routine that identifies if there are any out of balances between the SCF1340 RRCS submitted by the SP Campuses and the 480-35 and 180-35 generated at Master File. The SCF1340 is a control report that categorizes pre-journalized money transactions submitted by the Campuses for posting at Master File accounts. The categories include current revenue receipts, future revenue receipts and non-revenue receipt monies based on the Julian Date of the DLN in consideration with the month ending date of the fiscal year reporting period. The 480-35 and 180-35 categorizes these transactions by tax class based on the MFT of the account they are actually posted to at Master File. This balance must be performed to validate the transactions posted to the MFT (tax class) in conjunction with SCCF and described as a PVS responsibility under IRM 3.17.221.11.2 (5). The 480-35 and 180-35 are input to the monthly which is generated at the close of the reporting period in accordance with the report cycle cut-off chart in the IRM 3.17.30.1341.1, Reports Cycle Cutoff Chart.

(3) The following are accessed to create the automated weekly Revenue Receipt Report: (See Exhibit 3.17.221-9)

1. Revenue Receipts Control Sheet (RRCS), weekly SCF1340 BMF and Daily SCF1340 IMF.

2. RRCS - Nullified Unpostable, GUF5342

3. EFTPS data, weekly control file, CMS2340 - Ogden Only

4. Submission Processing Campus Revenue Receipt Controls (BMF only), 160-02 (See Exhibit 3.17.221-12, Exhibit 3.17.221-13 and Exhibit 3.17.221-14)

(4) At the beginning of the calendar and fiscal year and whenever an out of balance condition occurs, the following comparisons need to be performed:

1. Each week print all Submission Processing campuses RRCS Grand Totals and compare these to the SC Total Summary amount on the 793-01 AAV Summary. (See Exhibit 3.17.221-11)

2. The SC Revenue Receipt Controls, Nullified, (160-02), totals should equal the Nullified Unpostable RRCS, GUF5342, current totals. For the first cycle of the fiscal year the 160-02 will reflect a zero balance for the first cycle and for the first cycle of the calendar year, verify by tax class the totals between the Nullified 160-02 and the Nullified Unpostable RRCS, GUF5342, current tax class totals.

3. The SC Revenue Receipt Controls, Reclassified, (160-02), totals must be offset balance between debits and credits. If not, initiate a IRWorks ticket, noting form number and tax classification the imbalance occurs in. Verify in the monthly processing of IMF and BMF 480/180-37 that the required adjustment has been made.

(5) The automated revenue receipt report performs the following steps when balancing the 35 run (180/480) summaries for each Submission Processing Campus.

1. Summarize the current amounts from the RRCS, SCF1340, plus the nullified current amounts (reversed) from the GUF5342, RRCS - Nullified, plus the CMS2340 amounts (Ogden only).

2. For BMF balancing, the total should equal the "Weekly Receipts Control Sheet for 160-02," (from run 180-35) total for each Submission Processing Campus.

3. For IMF balancing, the total should equal the "Daily Receipts Control Sheet for 480-35" (from run 480-35) total for each Submission Processing Campus.

4. For BMF balancing, the "Reclassification Control Sheet for run 160-02" totals (from run 180-35) should equal the reclassified totals from the 160-02. Also, the reclassified amounts on the 160-02 run control should always equal.

5. The "Reclassification Control Sheet for run 160-15" (from run 180-35) should equal the reclassification amounts from the 160-15 Recap, minus the 1040 amounts.

6. For IMF balancing, the total of 1040 amounts from the run 160-15 Recap should equal the "FUTA/IP DEBIT" from the Receipts Control Sheet for 480-35.

(6) For any imbalance, research the RRCS SCF from and to control dates and reported Revenue Receipts money amounts, deletions reflected on the MCC 793-01 AAV Summary, mathematical errors made in totals or adjustments, and error records from the 180/480 processing.

1. If a balance is not attained, verify the items noted above in (5) a through (5) f.

2. Annotate the RRCS totals to reflect any ECC deletion honored during the initial processing runs.

3. Verify that document codes are revenue receipt doc codes.

4. Attempt clarification with the Submission Processing Campus.

5. If balance is not attained, prepare a IRWorks ticket to report the imbalance.

(7) To balance the Monthly Revenue Receipts, prepare weekly, the on-line Accounting and Operating Report for each Submission Processing Campus for identification by tax class and net total. This report is automated and captures the following data: (See Exhibit 3.17.221-15)

1. By tax class (net) the ending balance from the prior month. (October 1 begins with zero.)

2. By tax class (net) the Receipts Control Sheet amounts from the 35 run.

3. By tax class any future monies from the 35 run.

4. By tax class (net) the Reclassification Control Sheet from run 160-02 amounts from the 35 run.

5. By tax class (net) (reversed) the Reclassification Control Sheet from run 160-15 from the 35 run.

6. Enter any data adjustments for the month that affect the revenue receipt totals.

7. Cycles for the month are cumulated by the program when responding to a program prompt.

   Note: IMF Adjustments are entered weekly by direction from SPC.

(8) Weekly, review the on-line Revenue Receipt Report to monitor the reclassification or adjustments by tax class between runs 160-55-15, 180-35-13, and 160-43-25. (See Exhibit 3.17.221-16) Any difference should be reported by opening a IRWorks ticket.

(1) Imbalance conditions that affect all Submission Processing Campuses due to program or system trouble and complex situations unique to a Submission Processing Campus should be reported to the SP Headquarters Policy Analyst, as well as the Enterprise Service Desk (ESD) at 1-866-743-5748, option 2. ESD will assign the ticket to the appropriate IT Service Provider for resolution.

(2) The Headquarters RACS Team should be contacted at os.cfo.fm.a.s.revenue.systems.raec.section@irs.govfor all situations related to RRACS processing of assessments and refunds.

(1) Any adjustment to revenue receipts that changes what was sent to ECC or that will affect balancing for the current or subsequent month should be reported to the affected Submission Processing Campus.

(1) At the close of each month, the Submission Processing Campus will prepare Form 6168, General Ledger Reconciliation with ECC RACR. This form should be completed and forwarded to ECC by the 15th of the month following the report month. An original and copy of the BMF and the /IMF RACR will be sent on a weekly and monthly basis by the SPCs to ECC. ECC will verify the correctness of the debit and credit amounts for each reconciling item shown. (See Exhibit 3.17.221-23 )

(2) Verify the entries listed under "Entries posted to RACR."

1. These amounts will normally refer to the last Submission Processing Campus Recap, or Accounts Register, which the Submission Processing Campus had not processed at the time the Form 6168 was prepared.

2. These items are checked to insure correct reference to the applicable RACR and to preclude duplication of previously reported data.

(3) The Submission Processing Campus will identify entries under "Entries Posted to General Ledger" as items processed and journalized by the Submission Processing Campus but not posted to the RACR.

1. Questionable or problem entries will be identified by an asterisk (*) in the Action column.

2. Aged reconciled entries from the previous month should be identified by an asterisk (*).

(4) Processing Validation will verify receipt of the media transactions identified by the Submission Processing Campus to insure the media is received and processed by ECC.

1. Differences noted will be identified by an asterisk.

2. ECC will annotate the cycles in which the data was processed.

(5) Contact the Submission Processing Campus for any item with an asterisk and coordinate to resolve the differences for entries reported the second time.

1. Annotate on the reverse side of the Form 6168, the date, name and phone number of Submission Processing Campus contact, and caller's initials.

2. Annotate for follow-up action required on unresolved differences.

(1) Within ten (10) workdays after receipt of and balancing the last Form 6168, General Ledger Reconciliation with ECC RACR, PVS will fax or e-mail any problem identified and not resolved to the RACS Team at Headquarters.

(2) The Form 6168 should be balanced by PVS within five workdays for the weekly IMF RACR and within 10 days for the monthly/IMF and BMF RACR.

(3) The file of original copies received from the Submission Processing Campuses will be maintained at ECC.

(1) Requests for deletions are normally received in the Master File Scheduling from a Submission Processing Campus, Headquarter's Office, or ECC IBM Support Branch. Two types of deletion requests are:

1. Generalized Mainline Framework (GMF) deletion

2. Resequence file deletion request (reject)

(2) Requests for deletion may also be initiated by Master File Branch (MFB), to correct stoppage problems in production runs.

(1) Requests for deletes from the Submission Processing Campuses will not be honored.

(1) Resequence file deletions (Rejects) are requested by Headquarters or ECC Mainframe Operations Branch via telephone, memorandum, or facsimile. These are rejected during processing of BPW/IPW 02 runs.

(2) These reject requests will be verified by the on-line Computing Center Journaling System (Info Notes).

(3) When the run controls indicate a Block Out of Balance (BOB) or rejected record, prepare a IRWorks to identify the rejected data.

(4) Rejected items will be used in balancing the BPW/IPW 02 run.

(5) Prepare DAV to notify the Submission Processing Campus of the reject.

1. Explain action to be taken by the Submission Processing Campus.

2. Attach a copy of the reject transaction to the DAV.

(6) Rejected records that contain money amounts must also be reported on the RACR.

(1) Computer production runs at ECC are audited by the Processing Validation Section for correctness and completeness of the data produced by the run.

(1) Whenever a control file is converted to electronic transmission via Network Data Mover (NDM) or Control D, ECC will no longer provide a paper document. Each Submission Processing Center upon receipt of the electronic transmission will be responsible for the distribution of the control data.

(1) ECC control and accountability for the TRDB begins with the acceptance of Submission Processing Campus data. Input files to TRDB processing are:

• ELF-10-004

• MGT-15-007

• EFS-55-003

• ERS-01-005

• ERS-05-007

• ELF-15-003

• ETD-68-003

• ETD-69-004

• EFS-33-002

• AMS-03-014

• 793-01-021

• GUF-51-108

• ERS-08-001

• EFS-55-003

• EFS-10-017

• ELF-61-020

• ELF-61-018

(2) The files are electronically transmitted (EDT'd) to ECC daily and should be transmitted by 6:00 p.m. EST Monday through Saturday. The exception is the AMS-03-014 file, which is received weekly.

(3) The initial acceptance of submission processing data is acknowledged with AAV's from the following runs:

• 793-0A

• 793-3A

• 793-4A

• 793-5A

• 793-6A

• 793-7A

• 793-8A

• 793-9A

• 793-1B

• 793-2B

• 793-AA

• 793-BA

• 793-CA

• 793-DA

• 793-EA

(4) The following is a breakdown of acceptance voucher runs by Submission Processing Campus input to the initial ECC input runs:

• 793-0A, ETD-68-003, RDB-GC

• 943-A, ELF-10-004, RDB-E0

• 793-4A, MGT-11-007, RDB-XX

• 793-5A, EFS-55-003, RDB-X1

• 793-6A, ERS-01-005, RDB-K0

• 793-7A, ERS-05-007, RDB-K1

• 793-8A, ELF-15-003, RDB-G9

• 793-9A, ETD-69-004, RDB-GA

• 793-1B, EFS-33-002, RDB-W1

• 793-2B, AMS-03-014, RDB-60

• 793-AA, EFS-10-017, RDB-XM

• 793-BA, ERS-08-001, RDB-C3

• 793-CA, GUF-51-018, RDB-CA

• 793-DA, ELF-61-020, RDB-A0

• 793-EA, ELF-61-018, RDB-A1

(1) PVS will verify the input of the Submission Processing Center data to Control D. Any discrepancies identified will be addressed via a IRWorks ticket.

(2) Output data files from the input runs listed above are reformatted and subsequently loaded to the TRDB.