3.17.221  Enterprise Computing Center Data Controls (Cont. 1)

3.17.221.8 
Reconciliation of Master File Balance

3.17.221.8.3  (01-01-2012)
Form 5198A, Reconciliation of Master File Balance (REC) and Reciprocal Accounting Control Record (RACR) Validation

  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 KISAM and Scheduling releases the refund files to FMS to generate control numbers for pre-edit. ECS38 and 39 files for IMF and a ECS41 file for BMF are created after the processing has completed and refund data files have been sent to FMS by scheduling section. There is an agreement that FMS will not issue refunds on the files until the certification files have been received. Automation creates the ECS certification files to transmit to FMS 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 can not be resolved, a Priority 1 ticket will be issued by the Master File Section (CSA/RPA) to the programmer. KISAM ticket priorities are listed below:

    Priorities
    Priority 1 - Immediate nationwide work stoppage
    • Assigned within 30 minutes

    • Updated hourly

    Priority 2 - Potential Work Stoppage - Could have impact on service to taxpayers
    • Assigned within 1 hour

    • Updated every 2 hours

    Priority 3 - Work Stoppage for 1 customer with no work-around
    • Assigned within 1 hour

    • Updated every 4 hours

    Priority 4 - Non-critical - No work stoppage and has a work-around
    • Assigned within 2 hours

    • Updated no later than 3 working days

    Priority 5 - Requests for non-production related services
    • Assigned within 2 hours

    • Updated no later than 5 working days

3.17.221.9  (01-01-2013)
CADE 2 Database Implementation (DI) Simplified Financial Report

  1. This section outlines the validation of the CADE 2 Database Implementation (DI) Simplified Financial Report against the IMF Recap Report 460-43-22.

3.17.221.9.1  (01-01-2014)
General

  1. The purpose of this validation is to ensure that the data on the CADE 2 Database matches the data on the corresponding cycle of the Individual Master File (IMF) Recap Report, 460-43-22. The validation is automated and produces a report that balances to the 460-43-22. Access this report on Control M. If the automation is turned off or the report is out of balance, PVS must perform a manual validation. See IRM 3.17.221.9.1.1.

3.17.221.9.1.1  (01-01-2013)
Manual Validation

  1. The CADE 2 Database will produce a Simplified Financial Report. Validate this report against the corresponding cycle of the IMF Recap Report, 460-43-22.

  2. Access the IMF Recap 460–43–022 on LARS, Control D or Control M.

  3. Access the DI Simplified Financial Report on Control D, Control M or the IBM Platform with ISPF 3.4 option.

  4. Using the National Summary section of the IMF Recap, validate the following by comparing the Recap to the DI Simplified Financial Report:

    1. Subtotal Credit (M0033)

    2. Subtotal Debit (M0029)

    3. Net MF balance (M0030)

  5. If in balance, complete report for auditing purposes.

  6. If out of balance, open a Priority 1 KISAM ticket. A group ticket is auto generated.

3.17.221.9.1.2  (01-01-2012)
Automated Report

  1. The automated report, PVSDI, can be found by using Control D from Control M panel or by using your TSOJ mainframe user id and password. Access the GUI interface report on Control D Web.

  2. The report must be sent no later then 1:00 PM each day the daily cycle runs.

3.17.221.10  (01-01-2012)
Refund Validation and Certification

  1. This section outlines refund processing procedures.

3.17.221.10.1  (01-01-2012)
General

  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 KISAM 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 KISAM tickets will notify the appropriate site.

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

  3. All refunds are paid by check or by electronic fund transfer by FMS.

  4. Refunds generated at ECC by weekly master file and daily IMF processing are transmitted electronically via CONNECT:Direct to FMS.

    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.

3.17.221.10.1.1  (01-01-2012)
PVS Validation Responsibilities - IMF

  1. The following additional IMF validation tasks must be performed daily by PVS following successful completion of IBM Master file Processing and all differences and/or error counts must be identified as acceptable reconciliation amounts prior to certifying refunds for release to FMS. Certifying refunds must be the first priority of work performed each day.

  2. Review C-List -check for out of balance conditions and ensure they were addressed and corrections are noted. Ensure all Log Analysis Reporting Service (LARS) out of balances have been corrected prior to certification of refunds.

    1. I = “in balance”

    2. O = “out of balance”

    3. Pay special attention to jobs for IMF 460 (02, 03, 07, 08, 10, 11, 12, and 15).

    4. If C-List shows an out of balance, check for a rerun that shows it in balance. If no rerun is found, the PVS technician notifies the Lead. The Lead will conduct additional research such as reviewing ENDEVOR transmittals, KISAM, and Processing notes. If no explanation is found, the Lead will issue an KISAM to the programmer requesting clarification and validation of activity.

  3. Confirm all refund files were successfully transferred to FMS.

    1. Check the record counts and total amounts

    2. Verify the date and control number(s) to make sure there are no control numbers listed as “Z99999”.

  4. Confirm receipt of confirmation from CSA/RPA area (via e-mail) that they have completed the QR (Quality Review) for 460-38 and 460-39. This is to ensure that the files are format compliant for FMS.

  5. Review IMFBAL (PVS automation tool) to ensure there are zeroes in the "difference column" . If any value other than zero is displayed, contact ADP programmer.

    1. Ensure all differences have been identified and are reconcilable prior to certification of refunds.

  6. Review and validate the following output controls by looking for counts in the error fields:

    • 460-17

    • 460-64

    • 460-35 *(see additional information under EOD0167 for 460-35-12) IRM 3.17.221.10.1.1(7)

    • 460-37

    • 460-38-15

    • 460-39-22

    • 460-72

    1. If error counts are found, the PVS Technician will report their findings to the PVS Lead for issuance of an KISAM alert to the programmer to determine next action and to confirm whether or not refunds should be held based on the findings and explanations from the responsible programmer.

  7. EOD0167 Validation of input to 460-35-12 - this validation needs to be performed daily.

  8. Review amount field listed as “Diff of Debit Totals and Credit Totals” in 460-43.

    1. The dollar amount should be zero. If not zero, the PVS technician notifies the PVS Lead to determine if an KISAM assigned to the program area is warranted to reconcile the difference.

    2. Ensure all differences have been identified and are reconcilable prior to certification of refunds.

  9. The following tasks must be performed, but certifying refunds is not dependent upon completion of these tasks:

  10. Review and validate the following output controls by looking for counts in the error fields:

    • 460-3A

    • 460-3E

    • 460-96

    1. Ensure all existing errors have been identified and are reconcilable. If error counts are found, the PVS Technician will report their findings to the PVS Lead for issuance of an KISAM alert to the programmer to determine next reconciliation action based on the findings and explanations from the responsible programmer.

  11. Ensure no schedules were omitted in transfer to FMS.

    1. Confirm all refund schedule numbers are in sequential order with no gaps between cycles. This must be a point of validation during the process. If this is validation point is not performed by IBM Scheduling, it should be performed by PVS.

3.17.221.10.1.2  (01-01-2012)
PVS Validation Responsibilities - BMF

  1. The following additional BMF validation tasks must be performed on Friday by PVS following successful completion of IBM Master file Processing and all differences and/or error counts must be identified as acceptable reconciliation amounts prior to certifying refunds for release to FMS. Certifying refunds must be the first priority of work on Friday for BMF validation.

  2. Review C-List -check for out of balance conditions and ensure they were addressed and corrections are noted. Ensure all Log Analysis Reporting Service (LARS) out of balances have been corrected prior to certification of refunds.

    1. I = “in balance”

    2. O = “out of balance”

    3. Pay special attention to jobs for BMF 160 (02, 03, 07, 08, 10, 11, 12, and 15).

    4. If C-List shows an out of balance, check for a rerun that shows it in balance. If no rerun is found, the PVS technician notifies the Lead. The Lead will conduct additional research such as reviewing ENDEVOR transmittals, KISAM, and Processing notes. If no explanation is found, the Lead will issue an KISAM to the programmer requesting clarification and validation of activity.

  3. Check BMF02SUM for counts listed in the 160-02-15/16 files.

    1. Check for stale CAWR records. If counts are listed in either the 160-02 15 or 16 files report to PVS Lead. PVS Lead will then initiate an KISAM ticket to the programmer for acceptance.

      Note:

      Even though this warrants an KISAM ticket, this does not hold up refunds from being submitted. These counts are expected and the programmer needs to know to review the records.

  4. Confirm all refund files were successfully transferred to FMS.

    1. Check the record counts and total amounts

    2. Verify the date and control number(s) to make sure there are no control numbers listed as “Z99999”.

  5. Confirm receipt of confirmation from CSA/RPA area (via e-mail) that they have completed the QR (Quality Review) for BPW 16041. This is to ensure that the files are format compliant for FMS.

  6. Review BMF Revenue Receipts Report (PVS automation tool) to ensure there are zeroes in the "difference column" . If any value other than zero is displayed, contact ADP programmer.

    1. Ensure all differences have been identified and are reconcilable prior to certification of refunds.

  7. Review and validate the following output controls by looking for counts in the error fields:

    • 160-17

    • 160-41–017

    1. If error counts are found, the PVS Technician will report their findings to the PVS Lead for issuance of an KISAM alert to the programmer to determine next action and to confirm whether or not refunds should be held based on the findings and explanations from the responsible programmer.

  8. Review Recap and check for errors. Also check amount field listed as "Diff of Debit Totals and Credit Totals" in 160-43.

    1. The dollar amount should be zero. If not zero, the PVS technician notifies the PVS Lead to determine if an KISAM ticket to the program area is needed to reconcile the difference.

    2. Ensure all differences have been identified and are reconcilable prior to certification of refunds.

3.17.221.10.1.3  (01-01-2012)
Refund Schedules

  1. The refund files will be transmitted to Financial Management Service (FMS) as follows:

    1. IMF EFT and paper refunds are processed daily and should be completed by 3:00 PM Eastern Time each workday; but may be no later than 5:00 Eastern Time the following workday if needed.

    2. BMF EFT and paper refunds are processed weekly and should be completed by 3:00 PM Eastern Time on Friday after BMF weekly processing; but may be no later than 5:00 PM Eastern Time the following Friday if needed.

3.17.221.10.1.4  (01-01-2011)
Avoidance of Late Transfers

  1. In the event ECC is unable to electronically transmit refund data, ECC management will make necessary arrangements to avoid late shipment.

3.17.221.10.2  (01-01-2012)
Regular, EFT, and Accelerated Refunds

  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).

3.17.221.10.2.1  (01-01-2012)
On-line Voucher Preparation

  1. Submit on–line Refund Vouchers. Advance copies of the online refund vouchers are sent to each Submission Processing Campus and are available to view through Control D.

  2. Inform the Data Entry Operator (DEO) who will perform the following:

    1. Download refund data from the mainframe to The C drive. See IRM 3.17.221.10.2.1 (3) below for instructions if you are not able download refunds from ECS.

    2. Upload data from the C drive to Secure Payment System (SPS).

    3. Correct or delete incorrect schedules rejected back to the edit queue.

    4. DEO verifies printed schedule record and money amounts of the IMF and BMF refund controls.

  3. Manual download instructions:

    1. Access C drive as normal, select first file, hold shift key to select all other files. Once all files have been highlighted, right click and click copy.

    2. Open a new e-mail and paste files in the e-mail, not in an attachment or subject line. Paste by right clicking and pasting. Files will be automatically placed in the attachment line.

    3. Forward e-mail to DEO.

    4. DEO will open e-mail. Copy files as in step 2. Then paste to desktop.

    5. Only step that will change is when you upload files to SPS you will not select the C drive. You will need to select desktop and highlight all your files, then submit and continue as usual.

  4. The Certifying Officer (CO) will do the following:

    1. Certify all correct schedules.

    2. Reject incorrect schedules back to the Edit Queue for correction or deletions.

    3. Transmit the Certification Payment Schedule to the SPS host at FMS.

    Note:

    A User Manual is available for SPS. When logged into SPS, click the question mark in the upper right hand corner. This will display the SPS User Manual.

  5. The Campus will validate the integrity of Form 1166 that the Campuses receive from ECC via a file transfer through Control D. To ensure there are no inconsistencies between the ALC Payment Details listing, verify the following:

    1. Place the original copy of the Secure Payment System Schedule in the refund suspense file. (See Exhibit 3.17.221-24)

    2. Schedule number on Form 1166 must match the schedule number on ECS run on Control D.

    3. Requested payment dates must match confirmed date.

    4. Record counts balance to the check/bond range; to ensure the correctness of the check bond range; subtract the ranges (highest figure subtracted from the lowest figure add on), the difference between the two check/bond ranges will match the record counts that are listed on from 1166.

    5. Monetary disbursements with net amount.

      Note:

      The information should be verified by an Accounting Technician daily for IMF and once a week for BMF to ensure any inconsistencies can be cleared before payments are disbursed. If all information from ECC Form 1166 corresponds with the ALC Payment Details listing, then no further action is needed. If there are inconsistencies between the two forms, contact ECC Processing Validation Section to investigate the inconsistencies.

3.17.221.10.3  (01-01-2012)
Error File Refunds

  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 KISAM 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 FMS.

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

3.17.221.10.4  (01-01-2012)
Notification of Refund Data

  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.

3.17.221.10.5  (01-01-2010)
Dropped File

  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 FMS for replacement media.

    1. File ID

    2. Batch

    3. Cycle

    4. Workgroup

3.17.221.10.6  (01-01-2013)
Authorization of Certifying Officers, and Other Secure Payment System (SPS) Personnel

  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 Financial Management Service (FMS) 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, FMS Form 2958

    • Certifying Officer — Designation For Certifying Officer, FMS 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, FMS 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, PO Box 12599, Kansas City, MO. 64116-0599.

    Note:

    In order to speed up the processing of the forms, it is an option to fax the forms to FMS. A tracking number must be obtained from the mail room and noted on the Fax Cover Sheet, clearly label UPS tracking number. Without the tracking number, FMS will not process the forms until the originals are received.

  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 FMS.

  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.

3.17.221.10.7  (01-01-2012)
Trusted Registration Agent (TRA) Instructions

  1. Requesting a new TRA:

    1. Complete Public Key Infrastructure (PKI) Support Nomination form, which is available at http://www.fms.treas.gov/sps/forms/FS-PKI-Support-Nomination-SBU.pdf 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 http://www.fms.treas.gov/sps/forms/FS-PKI-Cert-Action-Request-SBU.pdf. 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 FMS 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 FMS; 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 http://www.fms.treas.gov/sps/forms/FS-PKI-Cert-In-Person-Proofing-SBU.pdf 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 http://www.fms.treas.gov/sps/forms/FS-PKI-Subscriber-Agreement.pdf
      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 http://www.fms.treas.gov/sps/forms/FS-PKI-Cert-Action-Request-SBU.pdf 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 FMS 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 FMS; 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 http://www.fms.treas.gov/sps/forms/FS-PKI-Cert-In-Person-Proofing-SBU.pdf 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 http://www.fms.treas.gov/sps/forms/FS-PKI-Subscriber-Agreement.pdf
      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 210 form will be required with their new signature.

    2. Complete the PKI Certificate Action Request form, which is available athttp://www.fms.treas.gov/sps/forms/FS-PKI-Cert-Action-Request-SBU.pdf. 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 FMS 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 athttp://www.fms.treas.gov/sps/forms/FS-PKI-Cert-In-Person-Proofing-SBU.pdf 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 http://www.fms.treas.gov/sps/forms/FS-PKI-Cert-Action-Request-SBU.pdf 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 210 form (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 and each CO and each 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 a Employee or Contractor by checking the appropriate box.

3.17.221.11  (01-01-2012)
Revenue Receipts

  1. The following section defines procedures for processing revenue receipts.

3.17.221.11.1  (01-01-2013)
General Information

  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 DLNs 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.13.1.1, Reports Cycle Cutoff Dates.

  4. The report month cutoff (see cycle cutoff chart in IRM 3.17.30.13.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 TEP data to MasterFile on Thursday. If a holiday falls on a Thursday during the last cycle, the final transfer day will be Wednesday.

    Exception:

    If the last campus production day of the month falls on a Thursday, the cutoff cycle will be set to the prior cycle. For example: in May 2012, May 31st fell on a Thursday which started campus production cycle 2012/24. Therefore, the cycle cut-off for the month of May was set to the preceding cycle 2012/23.

  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 CP23 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.13.1.1, Reports Cycle Cutoff Chart.

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

    • Revenue Receipts Control Sheet, (RRCS) (SCF 13–40)

    • Nullified Unpostables RRCS (GUF 53–42)

    • EFTPS (CMS-23–40) - Ogden Only

3.17.221.11.2  (01-01-2012)
Balancing Revenue Receipts

  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 weekly Revenue Receipts Control Sheet, 180–35 (BMF), 480–35 (IMF), for each cycle. Any imbalance or processing discrepancy will be reported using KISAM.

  2. Automated Data Processing (ADP) system performs a weekly balancing routine that identifies if there are any out of balances between the weekly SCF1340 RRCS submitted by the SP Campuses and the Weekly 480-35 and 180-35 generated at masterfile. The weekly SCF1340 is a control report that categorizes pre-journalized money transactions submitted by the Campuses for posting at masterfile 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 masterfile. 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 weekly 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.13.1.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 SCF 13–40

    2. RRCS—Nullified Unpostable, GUF 53–42

    3. EFTPS data, weekly control file, CMS-23–40 - 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 preformed:

    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, GUF 53–42, 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, GUF 53–42, 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 an KISAM 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 weekly revenue receipt report performs the following steps when balancing the weekly 35 run (180/480) summaries for each Submission Processing Campus.

    1. Summarize the current amounts from the weekly RRCS, SCF 13–40, plus the nullified current amounts (reversed) from the GUF53–42, RRCS—Nullified, plus the CMS-23–40 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 "Weekly 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 an KISAM 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 an KISAM ticket.

3.17.221.11.3  (01-01-2012)
Problem Reporting

  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 at 267-941-3345, 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 RRACS Team should be contacted at *cfo.rfm.iracs@irs.gov for all situations related to RRACS processing of assessments and refunds.

3.17.221.11.4  (01-01-2012)
Revenue Receipt Adjustments

  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.

3.17.221.12  (01-01-2012)
General Ledger Reconciliation With Form 6168

  1. This section outlines verification procedures and the reporting requirements of Form 6168, General Ledger Reconciliation.

3.17.221.12.1  (01-01-2012)
Verification Procedures

  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.

3.17.221.12.2  (01-01-2010)
Reporting Requirements

  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 RRACS 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.

3.17.221.13  (01-01-2010)
Deletion Operations

  1. This section outlines deletion procedures.

3.17.221.13.1  (01-01-2010)
General

  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.

3.17.221.13.2  (01-01-2010)
Generalized Mainline Framework (GMF) Deletions

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

3.17.221.13.3  (01-01-2010)
Resequence File Deletions

  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 an KISAM 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.

3.17.221.14  (01-01-2010)
Release and Certification of Magnetic Tape Files

  1. This section defines and outlines procedures for the release and certification of magnetic tape files.

3.17.221.14.1  (01-01-2010)
General

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

3.17.221.14.2  (01-01-2010)
Releasing Procedures

  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.

3.17.221.15  (01-01-2010)
Tax Return Database (TRDB)

  1. This section provides information pertaining to the Tax Return Database (TRDB). The TRDB is the official repository of record for all electronically filed returns. TRDB jobs are systemically validated via LARS counters in run to run. No manual balancing is required.

3.17.221.15.1  (01-01-2010)
TRDB Processing

  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

3.17.221.15.2  (01-01-2010)
Daily Processing

  1. PVS will verify the input of the Submission Processing Center data to Control D. Any discrepancies identified will be addressed via an KISAM ticket.

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

Exhibit 3.17.221-1 
SC Trans Release Summary (Other) GMF–15–45

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-2 
SC Trans Release Summary (ELF Total Summary) GMF–15–45

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-3 
SC Revenue Receipts Control Sheet SCF–13–40

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-4 
Revenue Receipts Control Sheet Nullified Unpostables GUF–53–42

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-5 
Form F–9607–A, Controls Register (IMF)

This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-6 
Form F–9607, Controls Register (BMF)

This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-7 
Run 460–02 Total Output Transactions Control

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-8 
Form M–4496, Data Adjustment Voucher

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-9 
Revenue Receipt Report

This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-10 
Document Locator Number Format

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-11 
ECC Trans Release File Acceptance Voucher Summaries (793–01)

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-12 
Run 02 Primary SC Revenue Receipt Controls

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-13 
Run 02 Reclassified SC Revenue Receipt Controls

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-14 
Run 02 Nullified SC Revenue Receipt Controls

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-15 
Accounting and Operating Report

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-16 
PVS BMF Revenue Receipts Report

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-17 
Reciprocal Accounting Control Record

This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-18 
Reconciliation of Master File Balance, Computer Form 5198A

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-19 
Reconciliation of Master File Balance, Form 5198A

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-20 
Run 63 Resequence Controls

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-21 
Run 43 Recap of Assessments, Abatements, and Other Post-Journalized Transactions

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-22 
Run 15 Controls

This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-23 
General Ledger Reconciliation with ECC RACR, Form 6168

This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-24 
Secure Payment System Schedule

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-25 
Form 9633, File Search Request

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-26 
BPW and IPW Refund Report

This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-27 
ECC Trans Release File Acceptance Voucher Summaries

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-28 
EFTPS Revenue Receipts Control Sheet

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-29 
EFTPS Revenue Receipts Control Sheet

This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-30 
Designation for Certifying Officer Form

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-31 
PKI Certificate Action Request

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-32 
PKI Certificate Action Request

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-33 
Delegation of Authority Form

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-34 
Designation for SPS Data Entry Operator Form

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-35 
ECC TRANS RELEASE ACCEPTANCE VOUCHER SUMMARIES (793–04)

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-36 
GRAND TOTAL SUMMARY

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 3.17.221-37 
IMF MAINLINE SUMMARY

This image is too large to be displayed in the current screen. Please click the link to view the image.

More Internal Revenue Manual