3.17.30. SC Data Controls

(1) These instructions provide for use by the Data Controls function, also known as the Balancing function, in the Submission Processing Campus Accounting Operation. The balancing of daily, weekly and monthly reports are a mission critical function and must be completed timely.

(2) The Service Center Control File (SCCF) is a real time file designated to control all documents and revenues while accountable to the Submission Processing Campus. Each control is verified prior to being processed by the SCCF. Instructions within this IRM will explain and guide technicians on the balancing steps.

(3) Instructions on balancing the Form 3996, Revenue Receipts Recap, also included in the proceeding sections.

(1) The Director, Submission Processing, oversees the policies in this IRM and approves and authorizes the issuance of this Internal Management Document.

(2) The Operations Manager and Department Manager secure, assign and providing training for the staff needed to perform the task required throughout this instruction.

(3) The Frontline Manager assigns cases and controls the workflow. Accurate recording of hours and volume is required. Task of balancing and reporting is rotated periodically to mitigate the risk of fraud.

(4) The employee must ensure that the CRL, SCCF, and Tape Edit Processing (TEP) runs is properly balanced before succeeding runs get initiated or tapes get released to the Enterprise Computing Center.

(5) NOTE: While working assigned cases, SP employees may come across blocked accounts on IDRS. These accounts can be identified by an IDRS security violation message: "Unauthorized Access to This Account". Forward the transcript to your manager. Managers will notify the local Planning & Analysis Staff who will scan the transcript and send encrypted information to the ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ mailbox to request access to the account.  Managers will keep the original case in a file awaiting access (can take up to 5 business days). Once notified access is granted, the case can be processed following applicable procedures.

(1) Below is reference to the definitions of words/terms used while working with SCCF.

(2) A list of acronyms found throughout this IRM follows:

(1) The following manual sections, websites, or documents frequently used in conjunction with this IRM:

• Data Control balancing worksheets are located at WICASSp ADC - Home (sharepoint.com)

• Instruction Guide - ITM Course 10819/10820, Controlling and Balancing Service Center Data

• Instruction Guide - ITM Course 56359/56360, Processing SCCF Invalid Transcripts

• IRM 2.3, IDRS Terminal Responses

• IRM 2.4, IDRS Terminal Input

• IRM 3.10.5, Batch/Block Tracking System (BBTS)

• IRM 3.17.277, Electronic Payments

• IRM 3.40.37, General Instructions

• IRM 3.30.123, Processing Timeliness Criteria and Critical Dates

• IRM 3.17.63, Redesigned Revenue Accounting and Control System

• IRM 3.17.41, Accounting and Operating Reports

• IRM 3.17.46, Automated Non-Master File Accounting

• IRM 3.17.64, Accounting Control General Ledger Policies and Procedures

(1) The following SCF runs to use with the on-line SCCF.

1. SCF01 Control Record Validation. Validity checks of all control records received in batch processing. On-line control records pass through to other runs. Creates the Invalid Control Record List and the Block Sequence List.

2. SCF03 Control Record Posting. Consistency checks and posts all control records except on-line SCCF adjustments from SCFAJ. Creates the daily on-line delete file and the printed Block Delete Request List, SCF0341.

3. SCF05 Control File Analysis. Updates the SCCF file. Selects records for special transcripts and reports. Creates backup file. When this run is completed, real time may be brought up for SCFTR and SCFAJ.

4. SCF07 Control File Report and Transcripts. Creates print file for all SCCF reports.

5. SCF11 Control Record Reports. Creates the print file for control records from batch and on-line input.

6. SCF13 Revenue Receipts Reports. Analyzes the cumulative revenue receipts files and incoming control records, SCFRV records, and date records.

7. SCF15 Downloads the daily on-line delete file. Sorts the deletes into TEP sequence, and outputs a delete file for GMF15, which is normally run immediately.

8. SCF16 Updates the SCCF with ANMF 0–5 adjustments, centralized at KCSC.

9. SCF17 Downloads records of all SCCF command codes for processing into batch programs.

10. SCF83 Daily run to change the process date and optional criteria for reports to be produced by SCF07 and SCF13.

11. SCF96 Batch run to extract from the cumulative historic file all records that match historic reactivation request records. Generates informational posting record for each module reactivated by SCFTRH.

12. SCF97 Posts the extracted historic records onto the SCCF Database.

(1) SCCF control can be established in different ways.

1. Form 9382, Batch Transmittal—to establish non-remittance returns and documents through BBTS. (See IRM Figure 3.17.30-1).



2. Form 813, Document Register—to establish non-Residual Remittance Processing System (RRPS) remittance documents through the Integrated Submission and Remittance Processing System (ISRP). (See IRM Figure 3.17.30-2).



3. Remittance Processing System (RPS) Documents—all payments and returns processed through RPS establish on the SCCF directly from a control tape produced by the RPS system.

4. IDRS Blocks - all blocks processed through IDRS establish on the SCCF directly from a Control tape produced by the IDRS system.

5. Adjustment Codes - a record can be established on the SCCF with a SCCF Adjustment. IRM 3.17.30.5.1 and IRM 3.17.30.5.2 explain the adjustment codes for establishing SCCF records

6. Nullified Unpostables - Nullified unpostables with Action Codes 1 and 8 establish on the SCCF from a tape produced by the GUF.

7. IRP - Master Control Records (MCR) also get produced on a control tape from IRP OCR. Input System Source Code S identifies these MCRs.

8. Modernized Electronic File (MeF) programs generate master control records for the SCCF.

(1) The following information pertains to processing of MCR source documents.

3.17.30.3.2.3 (01-01-2011)

Form 813 Document Register

(1) Part 2 of every Form 813 is routed to Data Control by Clearing and Deposit or from other Submission Processing Campus functions which assign DLNs for remittance documents.

(2) The Form 813 should comprise 100 or fewer documents within the block.

(3) In the upper left part enter an Alpha Block Control number which is obtained from the Batching function.

(4) Run a tape on all Form 813’s and enter the count and amount on the cover sheet being routed to Data Conversion. The cover sheet may be used by RRACS for journalization (See IRM Figure 3.17.30-3).

(5) The Form 813 is routed to Data Conversion for a Master Control Record to be prepared unless the Form 813 is identified as one of the following:

• Form RPS 813

• Renumbered Reject

• Reinput Document

• Document Code 52 or 54

• RPS Document Remittance Register Report, ISR0541 (Form 813 equivalent)

• Form 813 originating from BBTS Manual Deposit

(6) NMF applications from Unidentified Remittance File (URF) should be established using Command Code SCFAJ, Reinput Source Code U.

(1) The Submission Processing Campus Accounting function receives Accounting Control packages for all deposits from the Receipt and Control Branch.

(2) Data Control uses parts of the package for SCCF balancing after Accounting Control balancing is completed.

(1) Master Control Records (MCR) established via BBTS will appear on the SCF1144. BBT0103 is the BBTS output file that is processed through GMF04 to establish the MCRs on SCCF. Verify input of the BBT0103 input file daily by reviewing the GMF0440 run control. The Master Control Records also appear on the BBTS report titled Sorted MCR Report in the report menu of BBTS.

3.17.30.3.4.3 (01-01-2010)

Form 8627 Control Record Listing (CRL) Balancing Worksheet

(1) Prepare Form 8627 (or local substitute) to balance current revenue receipt master control records to RRACS by tax class. (See IRM Figure 3.17.30-4).

1. Prepare a separate form for the IDRS, mainline, and RRPS parts of the Master CRL each day. The mainline part should be prepared immediately because the amounts have been pre-journalized from the deposit tickets. The IDRS and RRPS parts can be partially prepared, then completed when the deposits have journalized.

2. The Taxpayer Assistance Center (TAC) Offices process payments through IDRS CCPAYMT. The AORR and EOD 16 runs need to be balanced daily. If a payment previously deposited by the TAC Office that could not be input through IDRS, the TAC Office would prepare a Form 3244 to be processed manually. The deposit ticket will need to be split to balance the Mainline and IDRS Control Listing. If any discrepancies found, contact the correct TAC Office immediately.

3. Verify that all deposit amounts have properly classified on the MCRL and the general ledger.

4. Complete the top part by entering the amounts from the tax class summary at the end of the MCRL. If any tax class amounts change because of adjustments prepared from the MCRL, enter the corrected amount. (See IRM Figure 3.17.30-5).



5. Take all journal windows (210, 250, 400, etc.), add by tax class, and associate with the Form 8166, Input Reconciliation Sheet. List the journal and Form 8166 number on the bottom part of form by tax class. (See IRM Figure 3.17.30-6). Use the EOD 16 Report for journal windows needed to balance the IDRS MCRL.

(1) Most IMF and BMF payments process through the ISRP Residual Remittance Processing System (RRPS) and Lockbox. RRPS run ISR05 and Lockbox RPS01 generates a tape of master control records which process to the SCCF through RPS01, GMF04 and GMF06. On the same day, RPS 05 and RPS 07 creates blocks of transaction records which process through the regular series of GMF runs.

1. Only payments process through ISRP RPS.

2. Returns separate from the payments and route for non-remittance batching.

3. The DLN of the payment is assigned via ISRP RPS and will have the Julian Date of the deposit.

4. The DLN of the payment is assigned via Lockbox Bank programming with a unique FLC for the vendor site by campus. The DLN will have the Julian Date of the deposit.

5. ISRP sends a 170-batch journal daily to RRACS.

6. Lockbox sends a 180-batch journal daily to RRACS.

3.17.30.3.5.1 (01-01-2010)

Residual Remittance Processing System (RRPS) and Lockbox Payment Processing and Balancing

(1) Ensure that all RRPS and Lockbox transactions get verified in the processing system.

(2) Balance the STD and OCR Raw Data File Block and Document Count from all the daily RPS0541, RRPS Pre-Mainline Update Run Control Report to the Total Blocks and Total Count to the RPS0341, RRPS Remittance Recap and the Input Files records, and the GMF0440.

(3) Balance the Mainline Raw Data File, Internal Controls and Output Controls, Block and Document Counts on the RPS0740, RPS EIF Match Run Control Report to the RPS0341, Total Blocks and Total Count on the RPS Remittance Recap. (See IRM Figure 3.17.30-7 and Figure 3.17.30-8).

(4) Balance the Lockbox document count and total deposit credits from the RPS9720, OCR Block Detail Listing (last page of the report) to the RPS0341 (Lockbox), RPS Remittance Recap. If the reports do not balance, contact your Lockbox coordinator according to local procedures.

3.17.30.3.5.2 (01-01-2010)

Balancing Deposit Ticket to Service Center Control File (SCCF)

(1) Balance the Block Count, less Tax Class 9 Blocks, from the ISR0551, Deposit Summary Report to the RRPS Block Counts from the RPS0341, the RPS0541, and the GMF0440. User Fees will be included in the Tax Class figures. (See IRM Figure 3.17.30-9).

(2) Balance the Form 215-A, Deposit Ticket Amount, electronic form found on OTCNet and/or ECP programs, less Tax Class 9 Amount to the RPS0342, General Ledger Account Number List, Total Amount.

(3) Balance the SCF1142, MCRL to the RPS0341, RPS Remittance Recap by counts and amounts. (See IRM Figure 3.17.30-10 and Figure 3.17.30-11).

3.17.30.3.5.3 (01-01-2010)

Quick Count Residual Remittance Processing System (RRPS) Balancing

(1) Ensure that all RRPS payment transactions get verified in the processing system.

(2) Balance the SCF1142, MCRL and SCF1143, Recap of the MCRL by Account Description, Tax Class, Block Count, Document Count, and Amount to the following output reports:

• RPS Remittance Recap, RPS0341

• General Ledger Account List, RPS0342

• RRPS Document Remittance Register, ISR0541

• General Ledger Account List, ISR0542

Note: See IRM Figures (3.17.30-12 and 13).

(1) The Remittance Transaction Research (RTR) System is a database which stores information from the Remittance Register Report (Form 813) and the EndPoint Master Listing Report. This system replaces the printing process of these reports produced by ISRP and allows research to be done on-line. (See IRM Figure 3.17.30 -14).

(2) The RTR System allows the user to query for specific records. It is important to enter as much information as possible to narrow your query request. Information that may be used includes:

1. Deposit Date (MM/DD/YYYY).

2. Transaction Date-This is the transaction date used on the header of Form 813.

3. Transaction Code-The payment transaction code is used in the block header and is indicative of how the payment posted to the taxpayer's module.

4. MFT-This is the Master File Tax code that shows the type of tax paid.

5. Block DLN-This is the twelve-digit identifying number assigned to a block of payments.

6. Taxpayer Identification Number-This is used for posting a payment to a taxpayer's account. This field is entered with no hyphens.

7. Sequence Number-This is the two-digit identifier of the DLN. Each payment will have its own number.

8. Name Control-This is the first four letters of a taxpayer's name.

9. Tax Period-This is the period of a tax paid (YYYYMM).

10. Money Amount-This is the amount of the credit processed. A '$' sign and/or '.00' do not need to be input to query.

11. Transaction Date-This is the actual transaction date of the payment that posts to a taxpayer's account (MM/DD/YYYY).

(3) See the RTR Quick Reference Guide Version 1.1.0, for more information on this application.

(1) A copy of every Form 9382, Batch Transmittal, that is corrected or voided because of an error found by Data Conversion or Receipt and Control should be routed to Data Control.

(2) Be sure that the Transmittal provides sufficient audit trail information to document the change.

1. A voided transmittal should show the disposition of the documents by showing the cross-reference DLN or other reason for the batch to be cancelled.

2. A corrected transmittal should clearly show the original and new DLN or other information being changed.

(1) Submission Processing Campuses processing Modernized Electronic Filed (MeF) returns should assure that SCCF control is established for all returns accepted by MeF that all transactions get verified in the system. Manual balancing procedures will need to be followed whenever the automated MeF balancing is turned off or whenever the BAL6240 and the GMF2545 do not complete successfully.

(1) BAL6040 and 6140 are run control reports implemented in 2007. They generate through automated programming that total the MeF transmission, balance MeF to SCCF and scan for error code and invalid conditions. If any discrepancies (balancing or error codes) get identified, the automation will abort and the process will have to be completed manually, see IRM 3.17.30 3.8. These output records must be handled as a daily priority and verified prior to requesting the regular consolidated TEP. During the first week of the new year the MeF TEP runs will need to be balanced manually until the initial MeF runs can be verified as correct. BAL62 is the automated MeF TEP programming, refer to IRM 3.17.30.12.9.1.

1. BAL6040 will perform a balance between MeF0801 and MeF0802 and will build the block and document counts using these input files. The block and document counts will also be compared and validated against MeF0840. If the automation notes a difference in the block and/or document counts, the BAL60 will error and will require CSA intervention.

   Note: BAL6040 has sequence numbers that will be helpful in identifying any missed transfers from MeF.

2. BAL6140 will complete the balancing and validity process (MeF to SCCF).

3. Data Control must verify the accountability controls MeF0840 get loaded to Control D for viewing and retention.

4. Data Control must verify the automation reports BAL6140 completed successfully and is available for viewing and retention in Control D.

(1) SCRIPS is an input processing system which replaced the OCR (REI/Scan-Optics) systems in the Submission Processing Campuses. SCRIPS will process Form 941 and Form 940, Schedule K-1 and IRP. These forms will be scanned by SCRIPS and processed through DED, GMF, and SCCF.

(2) SCRIPS is an image capture and data processing system. Capturing images allows the system to use labor savings technologies, such as character recognition (both image and optical). Using these combined technologies, SCRIPS can offer a system that will reduce labor associated with handling paper and performing data entry.

(3) SCRIPS will be able to store and retrieve digitized images of Form 941, Form 940 and Form 1096 and Schedule K-1. SCRIPS will interface and be integrated into other input initiatives.

(4) The Block Header control data is recorded on computer tape. The information on the tape is then transferred to the SCCF. This process sets up or "establishes" the blocks on the SCCF. The information includes the block DLN, block control identification, batch control number and total volume in the block. The Accounting Function has the responsibility for the SCCF information. If the SCCF computer program detects an error in the information that is input to the file, the Block Header data will print out on an Invalid Listing that is worked primarily by the Accounting Function.

(1) To access any DLN on the SCCF, enter Command Code SCFTR, followed by the Master File System Code and the Block DLN, with a space only between the command code and the MFID code. (See IRM Figure 3.17.30-15).

(2) The Master File system codes:

• 1 - IMF

• 2 - BMF

• 3 - EPMF

• 5 - IRP

• 6 - NMF

(3) The DLN must be entered as 12 numbers without hyphens or spaces.

1. If the request has a non-number Master File System Code or less than twelve numbers in the DLN, the message "Invalid Request" is displayed. (See IRM Figure 3.17.30-16).



2. If more than thirteen numbers get entered, the first thirteen (MF System Code plus twelve-digit DLN) will be read.

(4) Use Tax Class 6 or the true tax class for NMF. If Tax Class 6 is used, the true tax class will be determined, validated, and displayed in the DLN of the transcript response, if needed.

(5) If the DLN is not on the SCCF for the requested Master File, the message "No Record of DLN" is displayed. (See IRM Figure 3.17.30-17).

1. Recheck the Master File and DLN of the request.

2. If any of the positions is entered incorrectly, overlay with the correct request and transmit.

(6) If the DLN is open on the SCCF, the complete transcript is displayed. (See IRM Figure 3.17.30-18).

(7) If multiple research attempts performed from the same Master File, the operator may tab twice after initial request to place the cursor on the first position of the DLN for overlaying the subsequent DLN.

(8) If the block is removed to the Historic transcript after conversion to the on-line SCCF, the response is an abbreviated record having only the block DLN and the latest historic cycle, plus a pre-formatted SCFTRH record to request reactivation of the historic transcript. If more research is necessary, transmit the SCFTRH request. See IRM 3.17.30.4.6 for more instructions.

(9) The on-line control file is updated continually for on-line SCCF adjustments and updated daily for batch processing at the conclusion of the SCF03 run.

(10) SCFTR displays up to 10 pages, with 15 control records per page. If more than 150 records input, some of the records would consolidate to prevent an overflow condition.

(11) Use the print option to get a copy of the transcript. For multi-page transcripts, this is the only way to see the entire record at one time. However, print the transcript only when necessary.

(1) All SCCF transcripts print or display in the same basic format. The top part identifies the current status of the block. (See IRM Figure 3.17.30-19).

(2) Each SCCF transcript displays six different count and amount balances. The total in-process balance is the sum of the Manual, Error, and Reject balances. The following paragraphs match the letters on IRM Figure 3.17.30 -19.

1. The Date is always the current date for on-line transcripts. For printed transcripts, the Date is the system date.

2. Block Document Locator Number

3. The Original balance normally reflects the figures on the block at the time it is established.

• The original count and amount can be increased by codes 7–0, 6–4, 6 –0, and 6–2 or decreased by code 8–0.

• Codes 6 - 4 (rejected unpostables), 6–0 (reinput unpostables) and 6–2 (deleted unpostables) will only increase the original count up to 100. If the count is already 100, From Codes 6 will decrease the good balance and increase the manual, reject, or delete balance.

(3) The manual balance represents items that set up on the SCCF but have not yet transcribed. This includes reinputs and reprocessables that have yet to be re-transcribed. (d)

• The manual balance is established or increased by control records 0–0, 2 –0, 3–0, 4–0, 5–0, 6–0, or 7–0.

• The manual balance is decreased with codes 0–2, 0–3, 0–4, 0–5, 1–2, 1–3, 1–4, 1–5, or 8–0.

(4) The Error balance represents items in the Input Correction inventory, including both error registers and Error Resolution System error items. The Error balance is increased with from-to codes 0–3 and 1–3 or decreased with codes 3–0, 3–2, 3–4, and 3–5. (e)

(5) The Reject balance represents items in the reject or ERS suspense inventories. (f)

• The Reject balance is increased with from-to codes 0–4, 1–4, 3–4, or 6–4.

• The Reject balance is decreased with codes 4–0, 4–2, or 4–5.

(6) The Delete balance is not an open balance but is provided for informational purposes to show items and money that deleted from the block. The Delete balance is increased with Codes 0–2, 1–2, 3–2, 4–2, or 6–2 and decreased with code 2–0. (g)

(7) The Good balance, also not an open balance, shows the count and amount sent to Enterprise Computing Center (ECC) for posting. The Good balance is increased with codes 0–5, 1–5, 3–5, and 4–5. The Good balance is always decreased with 5–0 and may be decreased with codes 0–0R, 6–0, 6–4, and 6–2. (h)

(8) The batch and program numbers (BP) are shown on most non-remittance blocks. (i)

(9) The Action Delete Status Indicator (ADSI) is off (0) unless a Trans Deletion Control Record or 7–7 SCCF adjustment is posted to the module. If the indicator is on (1), no Good Block Proof Record can post to the module. (j)

(10) The Block Status Code (S) identifies the current status of the Block on the SCCF. (k)

• A Active—Open manual, error, or reject balance

• D Being Deleted—An 8–2 adjustment is entered today

• H Historic—shown on a Historic transcript only

• I Inactive—No open manual, error, or reject balance

• S Shelved—Full paid DLN with no processing activity

(11) The Block Out of Balance Indicator (B) is 1 if the block is in BOB status or 0 for all other blocks. The indicator is turned on with a 0–1 control record or off with code 1–0, 1–2, 1–3, 1–4, or 1–5, or whenever the SCCF manual balance is reduced to zero. (l)

(12) The Age Counter (A) shows the number of times that a block is selected for the monthly SCCF age review. Each time the block is printed on the monthly age transcript, the indicator is increased by one. The indicator is never decreased, unless a Historic block is reactivated as a reprocessable. (m)

(13) The Historic Cycle (HC) is filled with zeros when the original block has never pulled off to a Historic. HC with a cycle number represents the latest cycle that a block has gone to the Historic file. (n)

(1) Each control record that posts to the SCCF is shown in the control record section of the transcript. (See IRM Figure 3.17.30-20).

(2) The on-line transcript displays one control record per line, while the printed transcript normally displays two, reading across.

1. For a printed transcript the first record is printed on the left side of the first line, the second record on the right side of the first line, the third record on the left side of the second line, and so on.

2. Renumber block proof and on-line SCCF adjustment records require an entire line because of the larger size of the record. The cross-reference DLN for renumber records is shown at the end of the record and the cross-reference serial number is shown in the second serial number position. For adjustments, the remarks field is shown at the end of the record. If the remarks field is entered as all numbers, it is displayed and formatted as a cross-reference DLN.

(1) This section prints only for the Invalid Transcript, SCF0743, and is displayed for on-line SCCF adjustments.

(2) Each control record that does not post to the SCCF is printed at the bottom of the transcript. For NR (no record) transcripts, this is the only section except for the DLN and transcript code.

(3) The standard elements of the invalid record is as follows: (See IRM Figure 3.17.30-21).

(4) The remaining elements vary with the type of control record. See IRM 3.17.30.4.5 for more information on the record formats.

(1) Frequently, when working the Invalid CRL or the SCCF Invalid Transcript, it is necessary to examine the complete invalid record.

(2) All control records have 92 characters. Positions 1–61 and 89–92 is standard, although some of the positions may be blank for some types of records.

(3) Position 1—Record Type ID Code—a

• 0—SCCF Adjustment

• 1—Master Control Record

• 2—BOB Control Record

• 4—Generated SCCF Adjustment

• 5—Reinput or Delete Block Proof Record or Trans Deletion Control Record

• 6—Renumber Block Proof Record or Renumber Adjustment Record

• 7—Good, Error, or Reject Block Proof Record

• 8—Block Out of Balance Release Record (passes through SCCF to PCD)

(4) Positions 2–4–SC Block Control Number. The alpha may be blank or present for any type of control record.—b

(5) Position 5—From Code. Must be 0–9 and a valid combination. See IRM 3.17.30.5.2. The From and To codes may be blank only for a Trans Deletion Control Record.—c

(6) Position 6—To Code. Must be 0–5, 7, 9, or blank and a valid combination. See IRM 3.17.30.5.2.—d

(7) Position 7—Reinput Source Code. This position must be blank, 4, E, H, N, R, or U.—e

• 4—Reinput

• E—Override error check for EPMF deletion

• H—Duplicate of Historic block

• N—Nullified Unpostable

• R—Reprocessable

• U—Application from Unidentified Remittance File

(8) Position 8—Master File System ID Code—f

• 1—Individual Master File (IMF)

• 2—Business Master File (BMF)

• 3—Employee Plans Master File (EPMF)

• 5—Information Returns Processing (IRP)

• 6—Non-Master File (NMF)

(9) Positions 9–19—Block DLN—g

(10) Position 20—DLN Year Digit—h

(11) Positions 21–24—Document Count—i

(12) Positions 25–28—Batch Number—j

(13) Positions 29–33—Program Number—k

(14) Positions 34–46—Credit Amount—l

(15) Positions 47–59—Debit Amount—m

(16) Positions 60–61—DLN Serial Number—n

(17) Positions 90–92—Control Record Error Codes—o

(1) Any module that has removed to the Historic Database in the current year or prior six years may be reactivated.

1. Modules with reprocessable or nullified unpostable activity automatically generate reactivation requests.

2. Modules that require research of the Historic transcript may be reactivated with Command Code SCFTR, definer H.

(2) Historic reactivation requests generate whenever a 0–0 R (reprocessable) or 6–4, 6–0, or some 6–2 (nullified) control record is posted to a SCCF module where only an abbreviated historic Database record is present.

1. Nullified control records (from–to code 6–2) deleted from IMF with an IMF DLN do not generate a reactivation request nor is the 6–2 control record posted to the SCCF Database. These control records appear on the IMF Nullified CRL for research capability but drop from further processing.

2. Only the reactivating control record is posted to the SCCF Database initially. When the generated request is processed in SCF96 and the SCF97, the old control records will be moved in front of the current activity on the SCCF module. (See IRM Figure 3.17.30-22).

3. SCCF modules reactivated by 6–2 control records will be in inactive status (Block Status Code I).

4. For aging purposes, reprocessables get treated as new modules, with the cycle of the 0–0 R record treated as the beginning cycle. For nullified unpostable records, the age indicator and original cycle of the historic record get kept and used for age analysis.



5. On rare occasions, a new block MCR may match the DLN of an abbreviated historic record for a block that is actually numbered ten years earlier. In this case, the MCR for the new block can be established only with Command Code SCFAJ, from–to code 0–0, reinput source code H. See transcript code 04 instructions in IRM 3.17.30.9.1.

(3) Blocks reactivated by SCFTRH request for historic research get created in Inactive status on the control file.

3.17.30.4.6.1 (01-01-2010)

Command Code SCFTR Transcripts

(1) In addition to the control records from the Historic, each reactivation from SCFTRH also generates an informational record to show the date and cycle of reactivation. (See IRM Figure 3.17.30-23).

1. This Record has record type 4, from–to code 9–9, control record source code H and the literal "HIST REACTIV" in the remarks field. This generated control record does not appear on the Adjustment CRL or any other listing.

2. With no further activity, the block will remain on the SCCF Database for two cycles from the date of the 9–9 H record, then removed to the next historic.

3. All module balances that were present on the Historic module will also be present on this type of reactivated module.

4. To request reactivation of a SCCF historic module, enter Command Code SCFTR in the normal manner.

5. If the block is not on the SCCF Database but is available for reactivation, the response will be an abbreviated SCCF transcript with only the DLN, historic cycle, and "H" block status code, plus a pre-formatted SCFTRH request record on the first line, and the message "The complete record of the DLN you requested is on the SCCF historic file. To request overnight reactivation for research, move to the end of the SCFTRH record, and transmit." (See IRM Figure 3.17.30-24).



6. The screen shows that the request is accepted. (See IRM Figure 3.17.30-25).



7. If a SCFTRH request is entered earlier in the day or a previous day but not yet processed, no damage will be done by entering the request again. The SCF17 program sorts all incoming reactivation requests, giving priority to requests from batch processing, then to the earliest on-line request. Duplicate requests will be dropped.

8. The SCFTRH format is also valid without first using SCFTR by entering the entire record. The format is the same as SCFTR, plus the historic cycle: SCFTRH 1292110281049 8913.

9. Any reactivation request that is created on-line from SCFTRH or SCFAJ since the last SCF17 run can be reviewed, corrected, canceled, or added by entering Command Code SCFTR with definer R. Requests generated from batch processing is passed directly to SCF17 and is not available for review.

3.17.30.4.6.2 (01-01-2010)

Command Code SCFTRR to Change or Delete Records

(1) Use SCFTRR to change or delete a record if a mistake is made while using SCFTRH or SCFAJ.

(2) Enter SCFTRR and transmit. The response is a screen display of all historic reactivation requests that have been created during the same day. (See IRM Figure 3.17.30-26).

(1) Adjustments to the SCCF get prepared because of SCCF posting errors, age review, and other problems identified during processing.

(2) Most adjustments to the SCCF get entered with Command Code SCFAJ. With SCFAJ, each adjustment is input, validated, and posted in real time.

1. Input of SCCF adjustments through the ISRP is still valid as a backup. However, ISRP input is recommended only when a large number of adjustments must be prepared or when Command Code SCFAJ is unavailable. Input of SCCF adjustments by punched card is no longer valid.

2. Form 4028 may be used as a backup source document for SCCF adjustments. The form may also be used if a SCCF adjustment must be prepared by someone who is not authorized to use SCFAJ.

3. Be sure to annotate the source listing or transcript with the adjustment information and date if Form 4028 is no longer being used as a paper record of the adjustment. The SCFAJ remarks field is the only other permanent audit trail.

(1) Every transaction that posts to the SCCF has a From Code and To Code.

1. For Block Proof Records, the From Code shows the balance being reduced, while the To Code shows the balance being increased.

2. SCCF adjustment Records may transfer a balance the same way as Block Proof Records, change the in-process balance only, or merely alter an indicator or code on the SCCF module.

(2) When the From and To Codes is in the range of 0 to 6, the standard meanings apply.

(1) The source code of adjustments identifies the area which initiated the record.

(2) The Control Record Source Code is required for every SCCF adjustment, including renumber adjustments. The code should show the source of the adjustment. When selecting a code, remember that only codes D and R will adjust the Block Proof Summary (PCD). Some of the codes that may be used:

(3) Source Code A is used when an adjustment is made from the Aged transcripts.

(4) Source Code B is used when an adjustment is made by the BOB function and for SCCF-related BOB code adjustments.

(5) Adjustments made from the CRL to correct error codes; to correct erroneous MCRs; and to create MCRs normally created on the Master CRL get assigned a source code C.

(6) Source Code D is used for ECC deletes.

(7) Source Code E is used by the Input Correction Operation.

(8) Source Code F identifies adjustments made by the ERS System or for an ERS record.

(9) Source Code J should be used whenever a RRACS journal action is required but not completed prior to input. Verify from the adjustment list that the journal action is being completed.

(10) Source Code K identifies adjustments originating from BBTS.

(11) Use Source Code M when none of the other Control Record source codes applies.

(12) Source Code N is used for adjustment to Nullified Unpostables.

(13) Source Code P pertains to the report period. Use code P as an alert that a correction to the MBCS may be necessary for revenue receipt balancing.

(14) Source Code R is used for adjustments input by the Reject Function.

(15) For all adjustments prepared as the result of the invalid posting transcript assign Source Code T.

(16) Any adjustment (regardless of source) for an IRP OCR block should include Source Code W.

(17) Other codes may be established locally with designated special meanings.

(1) Enter Command Code SCFAJF to display a SCCF adjustment screen. (See IRM Figure 3.17.30-28).

1. Overlay the Xs with the required information.

2. The Block DLN, From-To Code, Master File Code, and Remarks fields is mandatory.

3. The remaining fields should be entered when needed.

4. To blank a field after data is entered, overlay with spaces.

3.17.30.5.4.4 (01-01-2010)

Completed Screen

(1) After the screen is completed, recheck the record, especially the DLN, to ensure it is entered correctly, then transmit with the cursor in any location after the remarks data. (See IRM Figure 3.17.30-29).

(2) At the end of the day, SCFAJ adjustments get downloaded from real time on run SCF17, accumulated with all other control records in run SCF01, and listed on the SCF1141 Adjustment CRL. However, the record has already posted to the SCCF, so it is not passed to the SCF03 posting run. On-line SCCF adjustments is not revalidated by the batch programs. Only control records from other sources can be error coded or invalid.

(1) Each SCFAJ adjustment is immediately validated and posted to the SCCF using the same checks as for batch processing.

(2) If the SCFAJ record fails a CRL validity check, it is re-displayed with an error message. (See IRM Figure 3.17.30-30).

(3) The same error codes apply as for other control records on the CRL. Up to three error messages may display at one time.

(4) The valid error messages:

• Error Code 1: Invalid DLN

• Error Code 3: Bad Doc Code/Master File Combination

• Error Code 5: Credit or Debit Fields is Inconsistent

• Error Code 8: Invalid NMF Abstract Number

• Error Code 9: Invalid Document Count

• Error Code 0: Invalid Amount Field

• Error Code B: Invalid Reinput Source Code

• Error Code C: Incomplete Adjustment Record

• Error Code E: Invalid Entry for Deletion

• Error Code T: Invalid Tax Class

• Error Code U: Unable to Determine NMF True Tax Class

• Error Code Y: Invalid From–To Code

• Error Code Z: Invalid Master File System ID Code

(5) To correct the adjustment screen, overlay with correct data any field that is invalid. Be sure to blank out any field or position that should be removed.

(6) Move the cursor to the bottom of the screen and retransmit. (See IRM Figure 3.17.30-31).

(7) If you decide not to input the adjustment, overlay the SCFAJ command code with any other command and transmit.

3.17.30.5.5.2 (01-01-2010)

Service Center Control File (SCCF) Control Record Listing (CRL) Failed Validity Checks

(1) If the record does not post to the SCCF, control is passed to Command Code SCFTR which displays the Invalid Transcript. (See IRM Figure 3.17.30-32).

1. A transcript code is displayed to the left of the DLN. The standard invalid posting conditions of SCF0743 is made in real time and displayed.

2. The invalid record is shown at the bottom of the transcript.

3. When you determine what changes need to be made to the adjustment, enter SCFAJF and reenter the corrected record, and transmit. (See IRM Figure 3.17.30-33).



4. At any time, if you decide not to complete the adjustment, overlay the displayed command code and transmit.

5. If the adjustment does not find a matching DLN on the control file (and will not establish a module), the message "No Matching Record found on Database" is displayed.

6. To prevent incorrect data from posting to the SCCF, be sure to verify the information, especially the DLN, on the screen before transmitting. Once the adjustment has posted to the SCCF, it cannot be backed out, except by preparing a new adjustment, such as an 8–2 after a 0–0.

(1) Prepare Form 4028 when an adjustment to the SCCF will be input by ISRP or when required by local procedures to document an adjustment input on SCFAJ. (See IRM Figure 3.17.30-34).

1. Serial number—This is a Consecutive two-digit serial number assigned later for transcribing for the ISRP system. See IRM 3.17.30.5.8

2. SC or Alpha Block Control Number—For adjustments made from the Invalid Transcript, use the actual ABC to prevent problems on the Cycle Proof List. For other adjustments, the CRL Julian date or other audit trail information may be used.

(2) Adjustment Code

1. From Code—identifies where the record is coming from.

2. To Code—identifies where the record is moving to. (See IRM 3.17.30.5.2)

(3) Reinput Source Code

1. Enter N for a document that is unpostable. This code is necessary only with adjustment codes 00, 60, and 64.

2. Enter R for a reprocessable. This code is normally used with 00 but is necessary for 60 and 64 if a reprocessable subsequently unposts and is nullified. Code R should take precedence over the N.

3. Enter U for an IDRS or NMF application from the Unidentified Remittance File with adjustment code 00 or 05 only.

4. Code H will override the duplicate DLN check, reactivate the original module from Historic, and allow a block that completely processed to be set up with 00 again. The H is valid with SCFAJ only.

5. Code E will override the error check for multiple EPMF deletes but should rarely be used. Code E is valid only with Command Code SCFAJ.

6. Code 4 may be entered to show a Submission Processing Campus reinput.

(1) Prepare Form 4028-A to delete one DLN and simultaneously establish a renumber DLN on the SCCF. (See IRM Figure 3.17.30-35).

(2) Serial number—An assigned, consecutive two-digit number assigned later.

(3) SC or ABC number—the document ABC number or Julian date of the CRL.

(4) From Code—Normally "0" when prepared by Data Controls. The To Code is generated and not part of the input record.

(5) Reinput Source Code—"R" for Reprocessable, "N" for Nullified Unpostables, or "4" for Submission Processing Campus reinput. Usually blank.

(6) Master File Code—See top of form for the correct code.

(7) Original DLN—DLN of block being deleted.

(8) Document Count—Number of items being deleted and established under new DLN.

(9) Adjustment Amount—Credit or Debit Field Money amount being deleted and established under new DLN.

(10) Original Serial No.—the serial number of the deleted record, if only one document.

(11) Control Record Source Code—Enter a code from the listing in IRM 3.17.30.5.3.

(12) New Block DLN—the new DLN being established for the new block. A DLN must be entered. Literal is valid only from rejects or ERS.

(13) New Serial Number—the serial number of the New DLN, if only one document.

(14) New Master File—Enter the number code of the new Master File (as shown on top of form) whenever the new DLN is for a Master File other than the original DLN. Leave blank if the Master File is not changed.

(15) Remarks—Information for an audit trail and a good research tool.

(1) Form 4028-A and any Form 4028 that is not being input with SCFAJ must be blocked for input in the same manner as ISRP Master Control records. Form 4028 and Form 4028-A must be blocked separately.

1. Assign a consecutive two-digit serial number down the left column beginning with 00. The block cannot exceed 100 adjustment records. If no lines get skipped, the serial number is required only on the first and last entries on each page.

2. No sort by Master File is required.

(2) Verify the source document against the corresponding CRL list to assure that all SCCF adjustments is transcribed. (See IRM Figure 3.17.30-37).

(1) The Control Record Listing (CRL) is the name given to the consolidated listing of all records that get processed to the SCCF on a given day.

(2) Although the CRL is produced by a single computer run (SCF11), the control records get divided into five major segments and printed separately by Master File.

• Master Control Record List

• Control Record List Adjustment

• Tape Control Record List

• Renumber Control Record List

• Nullified Control Record List

(3) Some control records are so invalid that the CRL program cannot determine the correct list for displaying the record. These will be printed on the CRL-Invalid Control Records.

(4) The SCF01 Run Control Report (SCF0160) is a 3–page report listing all the inputs and outputs of SCF 01.

1. Page 1 lists all the input files with the number of records from each file. (See IRM Figure 3.17.30-38).



2. Use page 1 to identify any files or records that may have omitted from the run.

3. Page 1 may also be used to assist in the daily error and reject balancing.

4. Page 2 is the output report which lists the number of each type of control record being passed to subsequent runs.

5. Page 3 provides a copy of the date record information that was used to compute revenue receipts and determine whether the Cycle Proof List and Master Block Control Sheet would be printed.

6. The bottom of page 3 provides a count of each error code that is printed on the different sections of the CRL.

7. Instructions for updating the date record can be found in IRM 3.17.30.16.3

(1) Any control record that cannot be recognized as belonging in one of the regular CRL listings will be printed on the Control Record List-Invalid Records.

(2) The Invalid Records List is printed in the input format. (See IRM Figure 3.17.30-39).

(3) The conditions included on this listing is:

• Invalid Record Type Code. Position 1 must be 0,1,2,4,5,6,7, or 8.

• Invalid From-To Code. Positions 5 and 6 must be a valid From–To combination. See IRM 3.17.30.5.2.

• Invalid Master File System Code. Position 8 must be 1,2,3,4,5, or 6.

• Invalid tax class. Position 11 must be number and must be a valid tax class for the Master File in position 8.

• Invalid tax class/document code combination on a BOB Release Record. No correction is needed for the SCCF but an adjustment may be needed to the Block Proof Summary.

(4) To help identify and correct the invalid record, the entire record should be examined.

(5) The error code should identify the specific reason that the record is invalid.

(6) For NMF, if the tax class is not equal to 6 (except for SCCF-generated Trans Deletion Control Records), a blank tax class appears on the Invalid List.

(7) Error Codes T, U, V, X, Y, and Z is valid on this listing. See IRM 3.17.30.7.1.1 for procedures.

(1) All SCCF adjustments that pass the initial validity checks get printed on the Adjustments part of the CRL. (See IRM Figure 3.17.30-40).

(2) The records included on this listing include:

1. On-line adjustments from Command Code SCFAJ.

2. SCCF adjustments from Form 4028 input through ISRP.

3. Generated reinput or delete adjustments from Rejects or ERS.

4. Generated reinput or delete adjustments from IRP input correction.

5. Generated delete or count change adjustments from BOB correction.

6. Generated delete or count change adjustments from BBTS Batch Block volume change.

7. Trans Deletion Control Records from TEP.

8. NMF Trans Deletion Control Records from SCCF.

9. NMF applications from URF.

(3) Adjustments (other than on-line which already validated) that do not meet the preliminary validity checks will print on the Invalid Records List rather than the CRL Adjustment List.

1. The preliminary checks are for invalid tax class, Master File system code, record type code, and from-to-code.

2. Once the adjustment record passes these validity checks, the standard CRL error codes apply.

(4) The "CR CD" field is the Control Record Source Code. The codes get explained in IRM 3.17.30.5.3.

(5) The "RC" code is the Reinput Source Code. This field may be blank; significant Reinput Source Codes appearing on the Adjustment CRL is:

• Code "N" for nullified unpostable.

• Code "R" for a reprocessable return.

• Code "U" for an URF application.

• Code "H" shows bypass of an error check.

• Code "E" shows bypass of an error check.

• Code "4" shows a reinput. Although valid on any control record, this code should be present only on certain generated records but serves no function in controls processing.

(6) The "DC" code is the Delete Source Code.

• Code C shows a computer-generated delete or reinput from BOBs, errors, or tape edit processing.

• Code S is a TEP delete from an "S" coded delete.

• Code M is a TEP delete from an "M" code delete.

(7) For on-line SCCF adjustments, the Employee Number of the person entering the Command Code SCFAJ is printed.

(8) The "Net Increase or Decrease" in the summary section is the net effect on open SCCF balances.

• A record that adds to the manual, error, or reject balance is counted as an increase.

• A record that subtracts from these balances is counted as a decrease.

• An adjustment that moves money from one open balance to another, such as from errors to rejects, is not counted as a net change.

(9) The summary of the Adjustment CRL provides separate counts for the different types of records on the listing.

• Form 4028 Adjustments is the SCCF adjustments that is input by ISRP from Form 4028.

• SCFAJ Adjustments, the on-line adjustments that have previously validated and posted.

• Generated SCCF Adjustments have record type 4 and include count change adjustments from corrected block out of balance registers.

• Generated Reinputs and Deletes include Trans Deletion Control Records from the TEP and generated reinputs and deletes from rejects, ERS, and Block Out of Balance (BOB).

(1) The Control Record List-Master Control Records is a listing of blocks established on the SCCF. (See IRM Figure 3.17.30-41).

3.17.30.6.4.5 (01-01-2010)

Control Date Recap

(1) Each MCR list is accompanied by a Control Date Recap, summarizing by control date the amount of money received in each category. (See IRM Figure 3.17.30-42).

3.17.30.6.4.6 (01-01-2010)

Non-Pre-journalized (NPJ) Batch Recap

(1) The NPJ Batch Recap is also received as part of the MCR list and verifies the correct volumes. This listing is used to verify that all batch transmittals is transcribed. For Batch Recap balancing procedures, See IRM 3.17.30.3.4. (See IRM Figure 3.17.30-43).

(1) The Renumber Control Record List has all renumber block proof records and renumber adjustment records input through IDRS by the Rejects function using Command Code NWDLN. Renumber adjustments may also be input through ISRP using the Form 4028-A. (See IRM Figure 3.17.30-44).

(2) The renumbered transactions appearing on this listing can come from four sources:

• BOBS - From Code 1 (non-remit only)

• Rejects - From Code 4

• Input Correction - From Code 3 (IRP only)

• Renumber SCCF Adjustments from Form 4028-A

(3) The Renumber Block Proof Record posts to the old DLN with a cross-reference to the new DLN.

(4) Each renumber record includes either a new DLN or a literal in the renumber field. The valid literals:

• URF—Unidentified Remittance File

• EXC—Excess Collection

• SMCR—Small Debit/Credit write off

• DEPF—Deposit Fund

• WASH—Debit/Credit offset

• OTHER—Other write off, including prior fiscal year DLNs and non-revenue DLNs renumbered to Unidentified Remittance

(5) The Renumber Listing may be used to document entries for RRACS. Be sure that every remittance document with a new literal, a change in Master File, or change in tax class is accounted for by RRACS.

(6) A copy of the renumber listing should be sent to the reject function.

(7) The Renumber BPR is invalid if the new DLN is blank, incomplete, or is incompatible with the original DLN for revenue receipts. A literal is valid only with a remittance document. If invalid, the record will print with CRL Error Code 7.

(8) Renumbered transactions are also printed on a list sorted by new DLN. The New DLN Record List, SCF1148 allows cross-reference DLN research using either the new or the original DLN. (See IRM Figure 3.17.30-45).

1. This list provides document count total and net money amount total of new DLNs.

2. The original Master File system ID code will be shown if different from the new Master File.

3. This list is routed to Rejects daily for verification of renumbered documents prior to release to Batching.

4. Be sure to annotate the list before sending to Rejects, so that adjustments that failed to post may be corrected by Rejects.

3.17.30.6.5.1 (01-01-2010)

Renumber Reclassification Summary

(1) The Renumber Reclassification Summary, SCF1147, is used by RRACS for journalization of renumbered items.

(2) The "Pre-journalized" side of page 1 provides net reclassification of revenue receipts of journalization. The pre-journalized side is included on an output tape from SCCF (SCF1101) for interface with RRACS for automatic journalization. If changes or corrections is necessary for any part of the pre-journalized section, it must be coordinated with RACS. (See IRM Figure 3.17.30-46).

1. Every current fiscal year revenue receipt item that is renumbered to a new current fiscal year DLN or to URF is included and summarized under "Pre-journalized."

2. Both the debit and credit fields show a plus for an increase and a minus for a decrease to the respective field.

3. Net Reclass amounts are credit balance: Any net increase of a credit and net decrease of a debit is shown with a plus sign; any net increase of a debit and net decrease of a credit is shown with a minus sign.

4. All non-revenue receipt items renumbered to other non-revenue receipt DLNs or to EXC or SMCR is included under "Other Pre-journalized."

5. Items renumbered to literals DEPF, WASH, and OTHER is not included on page 1, but is included on page 3.

(3) Page 2 is used for RRACS journalization between the SCCF and other accounts. (See IRM Figure 3.17.30-47).

(4) Every DLN renumbered to a new Master File or to URF, EXC, or SMCR is included in Part 1, General Ledger Account Summary.

1. Part 1 is included on the SCF1101 tape interfaced to RRACS for automatic journalization.

2. No changes to Part 1 should be made without coordination with RACS.

(5) Every DLN renumbered to DEPF, WASH, or OTHER is included in Part 2, Miscellaneous Accounts.

1. Items included in Part 2 get included in the summary on page 3.

2. Journalization of Part 2 must be entered manually into the RRACS system.

(6) Each amount is listed with item count for easier association with the related transactions on the renumber list.

(7) All net amounts are credit balance: Any net increase of a credit or net decrease of a debit is shown with a plus sign; any net increase of a debit or net decrease of a credit is shown with a minus sign.

3.17.30.6.5.2 (01-01-2010)

Reclassification Summary

(1) Page 3 is a reclassification summary which includes items from page 2, Part 2, Miscellaneous Accounts, in DEPF, WASH, and OTHER. (See IRM Figure 3.17.30-48).

(2) This summary should be reviewed for accuracy and for potential effect on revenue receipt accounts before routing for journalization by manual entry into the RRACS system.

1. Corresponding WASH items of current fiscal year revenue receipts require RRACS window 250 reclassifications.

2. Annotate with any other changes based on a review of the documentation that should have been received from rejects.

(3) The literal OTHER may include prior fiscal year items and non-revenue items transferred to Unidentified Remittance. Annotate specific accounts and breakdown of amounts included in OTHER.

(4) Some of the items may affect other general ledger accounts.

(1) Any record that is rejected, reinput, or voided by the GUF will be printed on the weekly Nullified Control Record List. The format of the list is the same as the format of the Adjustment CRL, except the Reinput Source Code will always be Code "N". (See IRM Figure 3.17.30-49).

1. Rejected records (To Code 4) is those items that transferred directly from the Unpostable inventory to the Reject or ERS inventory with Unpostable Resolution Code 8.

2. Reinput records (To Code 0) should be used infrequently, normally only for records that cannot be rejected or voided. These records corrected with Unpostable Resolution code 1.

3. Any uncorrectable non pre-journalized document other than some returns can be voided from the unpostable file with Unpostable Resolution code 2 or D. These records have To Code 2.

(2) Rejected or reinput records is validated using standard CRL error codes.

(3) Voided unpostable records is validated by CRL error codes and is identified with either an asterisk (*) or an Error Code 5.

1. Records identified with an asterisk is invalid for SCF processing; no tries should be made to resolve these error codes. The records with the asterisk is not counted in the total error coded records.

2. Records identified with Error Code 5 shows an invalid condition of an attempt to void or delete an unpostable record having a money amount. These records deleted from the GUF system and must be controlled on SCCF. Correct the error coded record on SCFAJ with from–to code 6–0 for reinput. Resolution of Error Code 5 records should be coordinated with the unpostable function.

3. IMF Tax Class 4 unpostables with IMF DLNs closed with Resolution Code 2D is recorded on the SCF1149, Nullified CRL, for IMF TC 4 and is dropped from further SCCF processing.

4. IMF Tax Class 4 unpostables with IMF DLNs, which is closed with Resolution Codes 1 and 8, will be recorded on the SCF1149, Nullified CRL, for IMF, and will be processed in the normal manner as IMF.

(4) The Nullified Unpostables list is accompanied by a Control Date Recap, summarizing by control date money amount brought back onto the SCCF in each category. (See IRM Figure 3.17.30-50).

(5) See IRM 3.17.30.13.3 for instructions regarding the nullified listings produced by the GUF system.

(1) The Tape Control Record List has the control records for all documents going to errors, rejects, or good tape. (See IRM Figure 3.17.30-51).

1. Each block DLN can have good, error, and reject documents shown with counts and amounts on the same line.

2. Only the From Code (FC) is shown on the listing. The To Code is 5 for trans tape items, 3 for errors, and 4 for rejects.

3. The error codes are the same as the other CRL errors, except that only one code can be printed. If multiple error conditions exist, the other codes will be suppressed.

4. Error coded block proof records should be extremely rare, since each record is generated from a mainline program with its own validity checks.

5. One invalid condition that is not checked in mainline is a reprocessable document with money.

6. If the document is a true reprocessable and the money should not have transcribed, delete the block and reinput.

7. If the R code is incorrect, the return can be allowed to post and the SCCF adjusted manually.

8. If an unexplained error occurs, notify the Enterprise Computing Center, via IRworks, of the problem.

9. If the document must be deleted in TEP, add the record to the delete file using Command Code SCFDLA. Also prepare any necessary SCCF adjustments to put the documents back into manual balance on the SCCF.

10. The "TI" field is the Treasury Reports Data Indicator. Although the Treasury Report is not produced from SCCF controls, the indicator can still be used to identify ECC deletes or other blocks requiring adjustments to the report.

11. The "ABS NUM" field is the abstract number for NMF. This field is not currently used as the NMF records is input through SCFAJ.

(2) Error coded Good Block Proof Records is passed to the Revenue Receipts program and included on the RRCS. However, the error coded records do not try to post to the SCCF.

(3) The Control Date Recap-Good Block Proof Records is a summary by DLN control date, of all documents and amounts converted to good tape and listed on the corresponding Tape Control Record List. (See IRM Figure 3.17.30-52).

(4) The Block Sequence List is a listing of all block DLNs shown on the Tape CRL as going to good tape. This list is printed in tape sequence number order. An asterisk shows that the same block DLN appears twice. Normally, this is not an invalid condition as reprocessable block DLNs frequently get input twice on the same day. (See IRM Figure 3.17.30-53).

(1) Some records get consolidated prior to posting to the SCCF.

(2) Multiple control records for the same block DLN on the same day get consolidated in SCF01 when the following fields is the same on each record:

• Record type code—The code must not be 0 (SCCF adjustment) or 7 (good block proof record).

• Alpha block control (if present)

• From code

• To code

• Reinput source code (if present)

(3) When records get consolidated, the item counts and money amounts get added together. The DLN serial number on the consolidated record is XX. (See IRM Figure 3.17.30-54).

(4) Although the record on the SCCF is consolidated, each record is listed separately on the CRL. (See IRM Figure 3.17.30-55).

1. Use the CRL to research the serial number or money amounts of the individual records.

2. As the records have previously consolidated before trying to post to the SCCF, it will be necessary to research the CRL whenever an Invalid Transcript has an XX on the invalid record.

(1) Every control record is validity checked before attempting to post to ensure that each element of the record has valid data and is consistent with the other information on the control record.

1. Any control record that is invalid is identified with an error code and is not passed on for posting to the SCCF.

2. On-line SCCF adjustments get validity checked immediately and any error codes is identified and displayed for correction.

3. All other control records get validity checked in SCF01 and printed with the CRL in SCF11.

4. The instructions in this section apply to error codes for both on-line SCFAJ adjustments and SCF11 CRL errors.

(2) Compare the source document with the error coded record to determine the reason for the error.

1. If a keying error is made, use Command Code SCFAJ to enter the correct record.

2. The source document for most error codes on the printed CRL is a Form 9382 or Form 813.

(1) This error condition occurs whenever a character other than numbers or blanks is printed in the debit or credit amount field on the CRL. The condition can also occur if a blank is present in a money field that has significant data. (See IRM Figure 3.17.30-56).

(2) Review the source document or transaction to determine the correct amount. Input Command Code SCFAJ to reconstruct the error coded record. (See IRM Figure 3.17.30-57).

(3) Remember that amounts coded with Error Code 0 is not included in any of the tax class summaries, or control date recap totals. When the correct amounts are determined, the totals should be adjusted to include the error coded amounts.

(4) The page total amounts are unreliable if an Error Code 0 is present, because the program converts the invalid character to a number when the totals is computed.

(1) A control record will print with error code 1 if any of the following condition(s) is present: (See IRM Figure 3.17.30-58).

1. The DLN has a File Location Code that is invalid for the processing Submission Processing Campus. Area Office codes that were previously valid but transferred to other Submission Processing Campuses is now invalid regardless of year digit.

2. The DLN year digit is for the current year, and the control date is more than ten days later than the current processing date.

3. The DLN year digit is for next year.

   Exception: during the last ten days of the year, the year digit for the following year is valid if the control date is 001–010.

4. The DLN control date is other than 001–366 or 401–766.

5. The tax class/document code combination is invalid.

6. The NMF document code/block number combination does not represent a true tax class.

7. An NMF revenue receipt document code has a Submission Processing Campus code rather than Area Office code in the DLN.

8. The DLN has non-number characters.

9. The DLN serial number has other than two numbers or blanks.

(2) Review the source document for transcription errors and prepare any necessary SCCF adjustments. (See IRM Figure 3.17.30-59).

(3) If the error code is the result of a true numbering error, assign a new DLN according to local procedures.

(1) This error condition occurs whenever a control record has characteristics inconsistent with those prescribed for records from the shown source of input.

(2) The Submission Processing Campus identified in the link below is currently processing electronically filed documents. For these Centers, the Area Office codes listed in Section 4, Document 6209 is restricted for use as File Location Codes (FLC) in the DLN of electronically filed documents. SERP - IDRS Campus and File Location Codes - Section 4 - 6209 (irs.gov)

(3) For original MCRs (record type 1, From–To code 0–0, reinput source code blank) with the following document codes, if the FLC in the DLN is a restricted Area Office code, the corresponding Input System Source code must be present. (See IRM Figure 3.17.30-60).

(4) For every control record generated by the RPS, the program number and debit amount must be blank.

(5) Identify the source of input to determine the reason for the error code.

1. If a file location code reserved for electronic filing is erroneously assigned to a regular block, assign a new DLN and input Command Code SCFAJ to establish the record on the SCCF. (See IRM Figure 3.17.30-61).



2. If the record is not an original MCR, input Command Code SCFAJ to recreate the record with a Reinput Source Code.

(1) This condition occurs whenever the document code is not valid for any type of input. (See IRM Figure 3.17.30-62).

(2) Because the program is unable to recognize the document code, any money amount cannot be accumulated as pre-journalized. For this error code only, the money is automatically counted as other Pre-journalized.

(3) When an adjustment is prepared to establish the correct DLN, be sure to correct the PJ and OPJ totals. (See IRM Figure 3.17.30-63).

(1) This condition occurs in the following situations: (See IRM Figure 3.17.30-64).

1. An MCR matches the DLN of the previous record and does not have a reinput source code R (Reprocessable) or cross-reference DLN (renumber record).

2. An MCR, or Renumber record with a cross-referenced DLN matches the DLN and serial number of the previous record. For this check, the new serial number must be numbers, not blank.

3. The New DLN and serial number of a Renumber record with a cross-referenced DLN matches the New DLN and serial number of the previous record. For this check, the new DLN must be numbers, not a literal, and the new serial number must be numbers, not blank.

(2) Review the source documents for transcription errors or duplicate input. Prepare an adjustment to correct the record. (See IRM Figure 3.17.30-65).

(3) Coordinate the Renumbered duplicate DLN with the rejects function, if needed.

(1) This condition occurs in the following situations.

1. Any control record has significant amounts in both the credit and debit fields.

2. A debit amount is present for a document code that allows only credits. (See IRM Figure 3.17.30-66).



3. A credit amount is present for a document code that allows only debits.

4. An amount is present for a document code or Master File that allows only non-pre-journalized transactions.

5. Reinput source Code R (reprocessable) is present on a control record that has a debit or credit amount.

6. On the Nullified CRL, an unpostable control record having a money amount voided in GUF processing. See IRM 3.17.30.6.6.

(2) Review source document or block to determine the reason for the error. Prepare a SCCF Adjustment to input the correct record. (See IRM Figure 3.17.30-67).

(1) This condition occurs in the following situations: (See IRM Figure 3.17.30-68).

(2) A Renumber Block Proof Record has a literal in the new DLN field but the money amount is zero.

(3) The new DLN has other than twelve numbers or other than one of the following literals:

• URF—Unidentified Remittance File

• EXC—Excess Collection

• DEPF—Deposit Fund

• SMCR—Small Debit/credit write off

• WASH—washout of offsetting transaction

• OTHER—Other write off and PFY DLNs transferred to Unidentified Remittance

(4) The original DLN and new DLN is incompatible on revenue receipts.

1. If the original DLN has money and is for a revenue receipt document code and the Julian date/year is within the current fiscal year, then the new DLN must also have a revenue receipt document code and be within the current fiscal year.

2. If the original DLN (with money) is for a prior fiscal year or non-revenue receipt document code 45, 48, 51, 58 or 74, then the new DLN must also have a prior year date or a non-revenue receipt document code.

3. New DLN literal URF is valid only when the original DLN is for current year revenue receipts.

4. New DLN literal OTHER is valid for transfer of credits to the Unidentified account when the original DLN is prior fiscal year but, because IRS received date is less than one year old, the amount is acceptable to Unidentified.

5. New DLN literal EXC is valid only when the original DLN represents non-revenue receipts by doc code or Julian date/year.

(5) Review the source document to determine the reason for the error.

1. Most renumber records generated from the rejects or ERS system and have already removed from that system.

2. Coordinate with rejects to determine the correction. Rejects may assign another new DLN.

3. Input Command Code SCFAJ or prepare Form 4028-A to create the correct record. If SCFAJ is used, delete the original DLN with From–To Code 4–2 or 0–2 and establish the correct DLN with From–To Code 0–0. Be sure to include cross-reference DLNs on both records. (See IRM Figure 3.17.30-69).

(1) Every NMF good block proof record (From–To Code 0–5) for a revenue receipt document requires an abstract number.

1. For some documents the abstract number is generated by the SCCF program because only one number can be valid for the DLN. If the number is generated, an input abstract number is invalid with error code 8.

2. For all other NMF revenue receipt documents, a valid abstract number must be part of the input record or the record is invalid with error code 8. (See IRM Figure 3.17.30-70).

(2) See the table in IRM 3.17.30.18.3 for a list of NMF document codes, true tax classes, and abstract numbers.

(3) If the error coded good block proof record is a subsequent payment or other miscellaneous revenue receipt document code, the document must be renumbered to the blocking series indicative of the true tax class compatible with the abstract generated by Automated NMF account.

1. Renumbering by Form 4028-A for ISRP entry will provide audit trail on SCCF through the XREF DLN and SCF1146, Renumber CRL, as well as automatic reclassification from the SCF1147, Reclassification Summary.

2. If renumbering is done through Command Code SCFAJ, be sure to provide cross reference to both old and new DLNs via the Remarks field. Use Control Record Source Code J for pending reclassification by RRACS on Screen 250, which must be requested according to local procedures.

3. Annotate the Form 813 with the corrected blocking series and clear the good block proof record through Command Code SCFAJ in the normal manner.

(4) Determine the correct abstract number by reviewing the source document. If the abstract number cannot be determined from the Form 813, coordinate with the NMF accounting function for resolution.

(1) This condition occurs in the following situations (See IRM Figure 3.17.30-71).

1. The document count is not numbers. Blanks need converted to zeros prior to the check.

2. For MCRs, (From–To Code 0–0), and generated block proof records, the document count cannot be zero.

3. For all control records, the document count cannot be greater than 100.

(2) Review the source document or block. Determine the correct count. Create the correct record with a SCCF adjustment. (See IRM Figure 3.17.30-72).

(1) The reinput source code on all control records must be N, R, U, 4, H, E, or blank. For most mainline processing the code will be blank. (See IRM Figure 3.17.30-73).

(2) Review the source document to determine if the code should be present:

• N—Nullified

• R—Reprocessable

• U—Application from Unidentified

• 4—Reinput—This code is never required for control records

• H—Duplicate of Historic block (valid with SCFAJ only)

• E—Override for multiple EPMF deletions

(3) Input Command Code SCFAJ to reconstruct the error coded record. Leave the Reinput Source Code field blank unless one of the above codes clearly applies.

(1) Any SCCF adjustment code that affects a module balance must adjust the count or amount of that block, except From–To Code 8–2.

1. From–To Code 8–2 requires only the DLN in the adjustment record to delete the entire DLN module from SCCF in the next posting run.

2. From–to Codes 1–0, 7–7, 8–7, and 9–9 is exempt from this check, because no SCCF balance is ever affected by these codes.

3. All other SCCF adjustments must have an entry other than zero for document count, credit adjustment amount, or debit adjustment amount. (See IRM Figure 3.17.30-74).



4. Remarks are required entry for audit trail.

(2) Review the SCFAJ screen and the source document and overlay with the correct information.

(3) If the error code is on the CRL, it may be necessary to locate the original source listing or register.

(1) This on-line condition occurs for deletions of EPMF document codes 30, 37, or 38 in the following situations:

1. When the document count is 001 and the serial number field does not have two numbers.

2. When the document count is greater than 001 but is not equal to the total in-process count.

(2) Use of Reinput Source Code E overrides this error check. Use this rarely.

(1) This condition occurs on the Invalid Control Record List or SCFAJ adjustment whenever a tax class is input that is not numbers or not valid for the Master File. (See IRM Figure 3.17.30-75).

(2) Compare the DLN and Master File code of the record with the source document. When the reason for the error is determined, input a SCCF adjustment on SCFAJ to correct the record.

(1) This condition occurs for any NMF revenue receipt record in which the DLN does not represent a valid true tax class. (See IRM Figure 3.17.30-76).

1. Normally this code will occur in combination with other error codes, as the DLN is also invalid.

2. Error Code U will appear only on the Invalid Control Record List and on Command Code SCFAJ.

(2) Review the source document and the invalid record. Prepare the corrected record with SCFAJ.

(3) See the table in IRM 3.17.30.18.3 for a list of the valid tax classes for each document code.

(1) BOB release records (record type 8) get created to update the Block Proof Summary (PCD) by showing that a correction is entered for the BOB record. These records only get passed through the SCCF and do not post.

(2) If any of these records is invalid for any reason, they will be printed on the Invalid Control Record List.

(3) No correction to the SCCF is needed, but an adjustment to the Block Proof Summary may be necessary. See IRM 3.40.37, General Instructions.

(1) Only the following record type codes is valid in SCCF processing:

• Record Type 0—SCCF Adjustment

• Record Type 1—Master Control Record

• Record Type 2—BOB Control Record

• Record Type 4—Generated SCCF Adjustment

• Record Type 5—Reinput, Delete, or Trans Deletion Control Record

• Record Type 6—Renumber Control Record

• Record Type 7—Good, Error, or Reject Block Proof Record

• Record Type 8—BOB Release Record

(2) If any other record type ID code is read into the SCF01 program, it will be printed on the Invalid Control Record List.

(3) Examine the invalid record to determine if the record is actually intended for SCCF processing. If the record type is not transcribed correctly and the correct identity of the record is determined, input SCFAJ to post the record to the SCCF.

(1) Any record that is input to the SCCF with an invalid from–to code combination is error coded on the Invalid Control Record List or the SCFAJ screen with code Y. (See IRM Figure 3.17.30-77).

(2) See IRM 3.17.30.5.2 for a list of the valid code combinations.

(3) Review the invalid record and the source document to determine the correct from–to combination. Input Command Code SCFAJ to post the corrected record.

(1) Every valid control record must have one of the following Master File codes:

• Code 1—IMF

• Code 2—BMF

• Code 3—EPMF

• Code 5—IRP

• Code 6—NMF

(2) Any record with a Master File code other than 1–6 is printed on the Invalid Control Record List or displayed on the SCFAJ screen with error code Z. (See IRM Figure 3.17.30-78).

(3) Review the invalid record and the source document to determine the correct Master File. Then input the corrected record using Command Code SCFAJ.

(1) Although the asterisk (*) is not a true error code, an * will appear in the error code field whenever a control record that is invalid for SCF processing is introduced to SCCF. The * normally appears on the Nullified CRL for voided unpostable control records which require no action on SCCF.

(2) The asterisk (*) will appear by some adjustments which is valid for SCF processing; these should not be considered error coded adjustments. These adjustments get tape generated for deletion and restoration on the same day of non-scannable SCRIPS returns to the Database. Tape generated From–To Codes 2–0 and 0–2 for Form 1040-EZ will appear on the Adjustment CRL with asterisks.

(3) If there is an attempt to void an unpostable with a money amount (a condition which is invalid in SCF processing), the asterisk will be replaced by a true error code, Error Code 5. See IRM 3.17.30.7.7 and IRM 3.17.30.6.6.

(1) Each validated control record is systemically analyzed to assure compatibility for posting to the correct module on the SCCF Database.

1. A control record validated on-line by SCFAJ but incompatible with a SCCF module is immediately identified as an invalid transcript.

2. A control record validated in SCF01 through batch processing but incompatible with SCCF in SCF03 posting analysis is identified as an invalid transcript and printed on the Transcript Invalid Modules, SCF0743.

(2) Invalid transcripts get coded to identify the condition which makes the control record incompatible with SCCF. These codes is called transcript codes and apply to both on-line and printed transcripts. See IRM 3.17.30.9.

(3) On-line transcripts will appear on the invalid line at the bottom of the SCCF module display.

1. The invalid line is prefaced by "ADJ."

2. The invalid line has a from–to code and various data entered on the SCFAJ screen.

(4) Invalid transcripts on SCF0743 get printed with the correct SCCF module.

1. Each invalid is identified by Record Type. Record Types is literals indicative of the effect on SCCF by the from–to code. See IRM 3.17.30.8.2 through IRM 3.17.30.8.7.

2. Each invalid control record is printed in the original format.

3. Invalid transcripts for good tape transactions (Record Type GBP) must be resolved on a priority basis, prior to running the daily TEP (GMF15).

4. All transcripts should be resolved and SCCF adjustments input by the day following date of receipt.

(1) Record type code MCR shows that the control record causing the transcript is a Master Control Record. (See IRM Figure 3.17.30-79).

(2) Correction of the MCR record type depends on the type of error condition encountered.

1. Review the source document used for the establishing of the Master Control Record, normally BBTS Form 9382, Form 813, RRPS, or SCRIPTS.

2. Query the batch and program number on the BBTS system and review for transcribing errors.

3. Notify the RPS Function if a RPS MCR occurs.

4. Notify IDRS Function if an IDRS MCR occurs.

(3) This record type may have created a BOB condition if the documents show as input. Coordinate any corrective action with the BOB Function.

(1) Record type code ADJ shows a record causing the transcripts is an adjustment trying to post to the SCCF. This type of record normally appears with an SCFAJ screen but can be caused by a generated adjustment or ISRP Form 4028. (See IRM Figure 3.17.30-80).

(2) The type of error condition encounter determines the correction.

1. Review source document making sure the adjustment is prepared properly.

2. Review the Adjustment Control Record List for transcribing errors.

(3) If the adjustment to the SCCF is still necessary, input or overlay Command Code SCFAJ to reconstruct the invalid record.

(1) Record Type Code BCR is a BOB Control Record. Normally the invalid condition will be resolved automatically by the correction of the BOB register or by the input of Batch Transmittals or CRL SCCF adjustments.

(2) Coordinate any corrective action with the BOB Function.

(3) The BCR invalid transcript will print on SCF0743, Invalid Modules, with the money amount in the record without any SCCF validation. Verify and post the correct money amount to SCCF on the proper BCRs with the audit trail postings.

(1) Record Type Code E/R is an Error or Reject Block Proof Record. This record is in error status or reject status. (See IRM Figure 3.17.30-81).

(2) The E/R record type will be corrected according to type or error condition.

1. Analyze the source documents.

2. Determine if SCCF is in error or if deletion of the error or reject register is needed.

(3) If the SCCF is in error, input a SCCF adjustment to correct the SCCF and other adjustments to reconstruct the invalid records.

(4) If the block must be deleted notify Input Correction to delete all related ERS, error, and reject records. Be sure to include the control day (date of GMF listings) on each request for deletion of an error record.

1. Error registers (except IRP) should be coded with Action Code 3. Reject and IRP error registers should be coded 2–R.

2. For ERS, Action Code 660 should be entered with Command Code SSPND for items in the error or Command Code RJECT for items in the workable suspense inventory. Items in unworkable suspense should be activated with Command Code ACTVT, with "RJECT 660" entered the following day.

3. At Submission Processing Campus option, ERS records may be deleted by Data Control personnel who have Command Codes GTREC, RJECT, and ACTVT in their operator profile.

4. To verify that the required RJECT 660 is entered, receive a copy of the ERS Rejected Records List, ERS0540 or use Command Code ERINV.

(1) Record Type Code GBP shows that the record trying to post to the SCCF is a Good Block Proof Record. (See IRM Figure 3.17.30-82).

(2) For each GBP transcript, a record is added to the on-line delete file. See IRM 3.17.30.11.2 for instructions for the on-line delete file and Command Code SCFDL.

(3) These transcripts must be worked immediately to determine if the block must be deleted by TEP.

(1) Record Type Code BPR is a Delete, Renumber, or Reinput Block Proof Record. (See IRM Figure 3.17.30-83).

1. The delete BPR transcript occurs when the Trans Deletion Control Record or generated delete record from BOBs, errors, or rejects does not post to the SCCF.

2. The Renumber BPR is generated when a record on the CRL Renumber Transaction List does not post to the SCCF.

3. The Reinput BPR occurs when a reinput record from Rejects, Error, Nullified Unpostables, or BOB Function does not post to SCCF. The record appears on the CRL Adjustment List or CRL Nullified Unpostables List.

(2) Resolution of these record types will depend on the type of error condition occurred.

(3) Analyze the source documents and coordinate any corrective action with the function handling the input of the record.

(4) If the invalid record is necessary, reconstruct with a SCCF adjustment. A BPR with Transcript Code 07 will normally require no corrective action, because Input Correction is merely clearing deleted documents from their inventory at the request of data controls.

(1) Blocks of documents that input without the DLN being established on the SCCF is identified with BOB Code P.

(2) BOB P blocks get included in the regular BOB inventory, but a separate BOB P Code Block List (GMF0641) allows the Data Controls function to identify and resolve these blocks. (See IRM Figure 3.17.30-84).

(3) The BOB P Block List has five types of Blocks in the order listed:

1. Release Code B—These blocks corrected yesterday from BOB P status but is still in the BOB inventory with some other BOB code. These documents should be associated with the re-BOB registers and worked by the BOB unit.

2. Release Code C—These blocks have been corrected with the input of a BOB correction record. The documents will be released to the Input Correction Operation.

3. Release Code S—These Blocks have been corrected on the SCCF so that the BOB P condition no longer exists. Unless other BOB codes is present, all BOB P blocks is automatically rechecked daily against the SCCF. If the SCCF is corrected, the block is released from BOB status without the input of a correction record from the BOB register. These documents should be routed back to the BOB unit for release to Input Correction with other corrected BOBs.

4. Unresolved BOB P blocks—These blocks are carryover BOB P blocks that are unresolved from the previous day. The P–Date is other than the current date and the Release Code is blank.

5. New BOB P blocks—These blocks get identified by the current processing date in the P–Date column. The documents should be pulled from the carts of new BOB documents and routed to Data Controls.

(4) Resolve each block by ensuring that the Batch Transmittals is properly routed to Data Conversion. Review the CRL–MCRL to verify that adjustments have prepared for error coded records. If the wrong DLN is established on the SCCF, input Command Code SCFAJ to remove the incorrect DLN with From–To Code 0–2 and a separate adjustment to establish the correct DLN with From–To Code 0–0. Be sure to enter the cross-reference DLN in the remarks field for both adjustments.

(5) If the MCR is correct, but the wrong DLN is transcribed on the block header, annotate the block of documents and route the block immediately to the BOB unit for the correction to be input.

(6) Any BOB P block that also has other BOB conditions should be routed to the BOB unit as soon as the BOB P condition is identified and the correction prepared. The block will not be revalidated until a BOB correction record is input.

(7) It is important that blocks on the BOB P listing be pulled and resolved daily to assure proper document control and minimize the chance of lost blocks. It is also important to release the documents as soon as the Release Code appears on the BOB P list, because the BOB function and Input Correction Operation will be needing these documents on the same day that they appear on the listing.

(1) This transcript code occurs with any of the following conditions:

1. An original MCR or 0–0 SCCF adjustment tries to post to a module that is already on the SCCF or is present on the Historic Database file. (See IRM Figure 3.17.30-85).



2. A renumber MCR (cross-reference DLN present) tries to post to a module that already has a 0–0 record with the same number serial number.

3. A 0–0 SCFAJ record with reinput source code H tries to post to an active (open balance) module.

(2) Review the source document and SCCF module to determine the cause of the invalid condition. If necessary, research the historic by using command code SCFTR with definer H.

(3) If the DLN is transcribed incorrectly, input Command Code SCFAJ with From–To Code 0–0 to establish the correct DLN. (See IRM Figure 3.17.30-86).

(1) This condition occurs when the money amount on a control record is inconsistent with the amount present on the SCCF. Transcript Code 05 is created by one of the following conditions.

1. A control record with a debit amount tries to post to a credit module or a control record with a credit amount tries to post to a debit module.

2. A block proof record (record type 7) tries to post without an amount when the module has an open money amount. This check is bypassed for reprocessables or if money is deleted from the block. (See IRM Figure 3.17.30-87).

(2) The non-matching debit and credit condition should occur only for document codes 24, 45, 48, and 58 because other codes permit only debits or credits through the CRL.

1. If the control record is correct, input a SCCF adjustment with code 8–0 to delete the money.

2. Then input a second adjustment with code 7–0 to establish the correct money amount.

3. Also reconstruct any control records that failed to post.

4. If the SCCF is on-line, all adjustments are entered consecutively on the same day.

5. If the SCCF is correct, use the normal procedures to delete the transactions from TEP and request deletion of error and reject records. For record type ADJ, input Command Code SCFAJ to reconstruct the record with the proper amount field.

(3) For non-remittance items input to remittance blocks, review the source documents to determine if money should be present on the block or should not be present on the SCCF.

1. If the money amount is erroneously omitted from the block header, take the necessary action to have the block deleted and reinput.

2. If the block header is correct, use Command Code SCFAJ to reconstruct the invalid record and make any other corrections to the SCCF. The record that is invalid as a block proof record will be valid as a SCCF adjustment, even if no other adjustments get made unless other transcript conditions is present. (See IRM Figure 3.17.30-88).

(1) This condition occurs with any of the following situations. (See IRM Figure 3.17.30-89).

1. A 7–0 control record would increase the original count of the block to more than 100.

2. A 0–3 or 1–3 control record would increase the error count of the block to more than 100.

3. A 5–0,6–0, or 6–4 control record would increase the total in-process count of the block to more than 100.

4. A 6–4 control record would increase the reject count of the block to more than 100.

5. A control record would increase the manual, error, or reject balance to more than the original balance.

(2) Review the erroneous control record and the related source document.

1. If a GBP record is incorrect, code the corresponding record with "D" on SCFDL to delete in TEP. Notify Input Correction to delete erroneous E/R records.

2. Prepare any necessary adjustments to correct the proper DLN or to reverse an erroneous posting. (See IRM Figure 3.17.30-90).

(1) This condition occurs whenever the Action Delete Status Indicator (ADSI) is on and any of the following records tries to post to the SCCF: (See IRM Figure 3.17.30-91).

• Generated SCCF adjustment

• Reinput Block Proof Record

• Delete Block Proof Record

• Trans Deletion Control Record—This record will turn on the ADSI but will not post if the ADSI is already on.

• Good Block Proof Record

• Error Block Proof Record

• Reject Block Proof Record

(2) The ADSI is turned on whenever a Trans Deletion Control Record or a SCCF adjustment From—To Code 7–7 posts to a SCCF DLN. A Trans Deletion Control record is always generated by the TEP whenever a block is previously deleted.

(1) For an initial block, the sum of the good, error, and reject block proof records with From Code 0 or 1 must equal the original count and amount on the SCCF. (See IRM Figure 3.17.30-93).

1. This check is bypassed if the incoming control record has reinput source code R for reprocessable.

2. For the purposes of this check, a block is considered initial if the 0–0 control record did not have reinput source code R or N, and no control records other than 7–0, 8–0, or 0–1 have posted since the module’s previous creation.

(2) Review the transcript and MCR source documents, Form 9382 or Form 813 to assure that the SCCF is correct. Be alert for adjustments made in error. Reverse and remake these adjustments as necessary.

(3) Review the block of documents for a missing document. The documents can normally be located in the Input Correction Operation. Check to see if notification is sent to accounting to increase or decrease volume from Receipt and Control Branch.

1. Prepare the necessary adjustment to correct the SCCF.

2. Prepare an adjustment to post the GBP record and/or the E/R record. (See IRM Figure 3.17.30-94).

(4) If a document failed to be transcribed, delete the GBP by entering Action Code D on the SCFDL record. Notify Input Correction to delete the records in error and reject status or see IRM 3.17.30.8.5. Pull the block for future processing.

(1) This condition occurs with any of the following situations: (See IRM Figure 3.17.30-95).

1. An 0–3, 1–3, 0–4, or 1–4 control record would reduce the Manual count or amount to less than zero.

2. An 8–0 control record would reduce the original count or amount to less than zero.

3. An 0–2, 1–2, 3–2, 4–2, 0–5, 1–5, 3–5 or 4–5 control record would reduce the total in-process count or amount to less than zero.

4. A control record with From Code 3 would reduce the error count or amount to less than zero.

5. A control record with From Code 4 would reduce the reject count or amount to less than zero.

6. A nullified unpostable 6-4 control record does not post. IDRS will not allow a 6-4 to be coded. See 3.17.30.9.6(6) for posting instructions.

(2) Review the erroneous or duplicate record that created the condition. If the SCCF is in error, prepare an adjustment to correct the balance on the SCCF or reverse the erroneous posting. (See IRM Figure 3.17.30-96).

(3) Review the source documents.

(4) If a GBP record is incorrect, enter Command Code SCFDL, and enter code D in the Action column for the block to be deleted. Notify Input Correction section to delete any error and reject items or see IRM 3.17.30.8.5. Pull documents for future processing.

(5) If the record has failed to post because of a previous duplicate posting, prepare adjustments to reverse the erroneous postings on the SCCF. Initiate action to delete any unposted duplicate items. Also, post the control record that has transcripted.

(6) Input the following adjustments to post an Error/Reject error for a 6-4 control record.

1. Input 7-0 for count and money.

2. Input 0-4 for count and money.

3. Input 9-9 for audit trail purposes noting that the system will not allow a 6-4 posting.

(1) This condition occurs whenever a control record would reduce any SCCF count to zero while the corresponding amount is still present. (See IRM Figure 3.17.30-97).

1. The amount can be removed with items still present using SCFAJ. Thus, money can be moved to unidentified or another document without affecting the DLN of the original document.

2. A reprocessable document previously having money can be created on an existing SCCF module without causing a transcript condition.

(2) This condition occurs whenever a Good Block Proof Record (record type 7) would reduce any in-process amount to zero while the corresponding count is still present.

(3) Review the source documents.

1. If the SCCF is in error, prepare the necessary adjustment and post the transcript record. (See IRM Figure 3.17.30-98).



2. If the record ADJ or BPR is necessary, reconstruct the record.

3. If the GBP or E/R record is incorrect, have the transactions deleted by coding the record with a D on the SCFDL file.

4. Notify the Input Correction Operation to delete the error and reject records or See IRM 3.17.30.8.5.

5. If the record has failed to post because of a previous duplicate posting, prepare a 5–0 adjustment to reverse the erroneous posting on the SCCF. Initiate action to reverse any erroneously posted transactions or to delete any unposted duplicate items. Also, reconstruct the control record that has transcripted.

(1) This transcript will print whenever a SCCF adjustment with From–To Code 8–2 is entered to delete a block from the SCCF. (See IRM Figure 3.17.30-99).

(2) This is not an invalid condition and requires no corrective action. However, the transcript should be kept for reference if more actions will be taken on the block. The 8–2 action is taken when a SCCF module has exceeded the 150-transcript line limitation. These modules require reconstruction of the module by consolidating "like" from and to codes within the module. Reconstruction must be completed the day the module appears on the invalid transcript listing to ensure the database record is restored timely. Refer to IRM 3.17.30.10.5 for detailed instructions.

(1) This code is caused by the input of a control record tape in the incorrect posting sequence.

(2) Contact the computing center according to local procedures. The computing center will probably rerun the program that caused the out of sequence condition, then rerun the SCCF.

(1) The SCCF program allows a maximum of 149 transactions on a single SCCF module. (See IRM Figure 3.17.30-100).

(2) The Transcript Code MX condition occurs when the 150th record tries to post.

(3) Input a SCCF adjustment with code 8–2 to delete the block from the SCCF. The program will allow this record to post as the 150th.

(4) See IRM 3.17.30.10.5 for correction procedures.

(1) This condition occurs whenever a control record, other than a record that normally establishes a block, tries to post to a DLN that is not on the SCCF. (See IRM Figure 3.17.30-101).

(2) From–To Codes that normally establish a block on the SCCF is 0–0R, 0–0, 6–0, and 6–4.

(3) Trace record trying to post to source documents for possible corrections. Prepare the necessary adjustments. (See IRM Figure 3.17.30-102).

(1) These transcripts get generated to provide immediate SCCF research for SCCF related BOB conditions. Technicians resolving blocks out of balance should be encouraged to use SCFTR for more current information.

(2) Each BOB code N, Q, R, or S will automatically produce a SCCF transcript BN, BQ, or BS; BOB Code P will produce a SCCF transcript for a BCR with Transcript Code NR (no record on SCCF).

(3) The BOB Control Record is not automatically invalid and will post to the SCCF if a module is available. Any other control record trying to post after the BOB Control Record (on the same day) will be invalid.

(4) No corrective action is required for the transcript unless invalid records is present.

(5) Route all BN, BQ, BR, and BS transcripts for association with the BOB register.

(6) Following resolution of BCRs, provide audit trail on SCCF with SCFAJ postings to show cross-reference DLNs in Remarks.

1. Post From–To Code 1–0 with the ABC of the block erroneously input to the DLN under which this BCR posted to turn off the BOB indicator unless there is a valid unresolved BCR for this block. In Remarks show the correct DLN as a cross reference.

2. If there is a valid unresolved BCR posted to the block, use From–To Code 9–9 rather than 1–0 (leaving BOB indicator on for the valid BCR) with the correct DLN in the Remarks section on the SCFAJ screen or correct column of the Form 4028.

3. Post From–To Code 0–1 with the ABC to the correct DLN, showing in remarks the DLN to which the BCR is initially input as a cross reference.

4. Whenever it is inappropriate to turn on or turn off the BOB indicator (From–To Code 0–1 or 1–0), use SCFAJ with From–To Code 9–9 to show the cross-reference DLNs for both old and new DLNs in the Remarks field.

(7) The audit trail may be further enhanced by posting the corresponding money amounts whenever available for verification.

(1) The Tape Control Record List is a list of all blocks of data in DLN Sequence in which the blocks or part of blocks which went to "good tape", "error tape", or rejected from normal processing. (See IRM Figure 3.17.30-103).

(2) The listing shows:

1. The part of a block that is previously placed on the Submission Processing Campus Transaction Tape for processing to the Master File.

2. The part of each block, if any, which is placed on the Submission Processing Campus Error Tape file or ERS error file.

3. The part of each block, if any, which is placed on the SC Reject Control File or ERS suspense file.

3.17.30.10.1.3 (01-01-2010)

Other Records

(1) Along with the Block Proof Records listing come the following:

1. Revenue Receipts Control Sheet (RRCS)—a breakout by tax classes of all amounts converted to tape to be transmitted to ECC. (See IRM Figure 3.17.30-104).



2. SCF0142, Block Sequence List (BSL)—A listing of DLNs for all blocks converted to good tape in the sequence in which they appear on good transaction tape. This listing is to be used for deletions due to tape "read fail" and other error conditions. The BSL may also be used to identify discrepancies between the TEP and SCF1152, Good Block Proof Records list. (See IRM Figure 3.17.30-105).



3. Control Date Recap, Good Block Proof Records—A summary by DLN Control Date of all documents and amounts converted to good tape and listed on the corresponding Block Proof Record list. (See IRM Figure 3.17.30-106).

(1) A daily RRCS is received with the Tape CRL. The summaries get broken into tax class on BMF and into tax class 2 and 4 for IMF.

1. "Current" includes those Revenue Receipt items which have a DLN date which falls within the current report period.

2. "Future" includes those Revenue Receipts items which have a DLN date which is later than the current report period.

3. "Other" includes those Revenue Receipts items which have a DLN date which is earlier than the beginning of the report period. It also includes pre-journalized amounts which is not Revenue Receipts or adjustments affecting deposits. The non-revenue receipt document codes are 45, 48, 51, 58 and 74.

3.17.30.10.2.1 (01-01-2010)

Manual Adjustments on the Daily Revenue Receipts Control Sheet (RRCS)

(1) When money is deleted from the Tape CRL by a Submission Processing Campus deletion, manually adjust all totals affected by the delete. Hold a copy of the daily RRCS to balance to the weekly.

1. Weekly, at the end of the cycle, request the Enterprise Computing Center to run a weekly RRCS. The SCF83 file is modified to include a "W" in the Revenue Receipts Frequency Indicator when the weekly RRCS is run. This file is updated by the Enterprise Computing Center upon request.

2. The weekly RRCS is a summation of all Revenue Receipts transferred to ECC on the transaction tapes. (See IRM Figure 3.17.30-108).

(1) The Control File Summary, SCF0742, is printed for each Master File with a total summary of all Master Files.

(2) The summary provides various information relative to the modules on the current SCCF Database.

3.17.30.10.3.4 (01-01-2010)

In-Process Worksheet

(1) The Worksheet In-Process Total (count and amount) represents the results of posting to SCCF all valid control records on the current days SCCF reports. (See IRM Figure 3.17.30-110).

1. Compare this worksheet total to the actual In-Process Total count and amount on line 4 of SCF0742.

2. Any difference should be identified and correctly reconciled.

3. The error coded control records from the CRL components of SCF11 is itemized separately with block counts, document counts, and net amounts.

4. These control records are considered to be pending and require individual analyses and proper manual adjustments to SCCF.

5. Error coded good block proof records on SCF1151, Tape CRL, require priority analysis since, if deletion is necessary, the DLN must be added to the daily delete file with SCFDLA prior to running GMF.

(1) Raw and Correction GMF and ERS run controls should be balanced to the error and reject counts on the TCRL and the SCCF to ensure that GMF and ERS tapes input properly.

(2) The Raw Run Control Report (GMF0740), Correction Run Control Report (GMF0840), Error Resolution Inventory Control Report (ERS1747), F1040 Doc Perfection Run Control Report (GMF3740), and the Unpostable Controls (GUF5340) should provide the necessary tools for this balancing. Campuses may also refer to BAL0240 for a quick count balance of inventories.

3.17.30.10.4.1 (01-01-2010)

Daily Balancing of New Error Records

(1) Daily balancing of new error records.

1. Add the Error Count for all Tape CRLs (SCF1151). The total should equal the sum of "Raw Documents to GMF Error Status" and "Raw Documents to ERS File" on the Raw Run Control Report (GMF0740, page 5), less the "GUF records to ERS" (GMF0740, page 4, plus "MeF Documents to Error Status, AWF" (GMF2740, page 3), less "GUF Records to ERS" (GMF3740, page 4), plus "Raw Docs to Error Status" (GMF3740, page 2). (See IRM Figure 3.17.30-111).

3.17.30.10.4.2 (01-01-2010)

New Reject Records

(1) Daily balancing of new reject records.

1. Add the Reject Block Proof Record document counts for all Master Files "from Raw" and "from BOB", from the summaries of (SCF1151). The total should equal the "Raw Documents to Reject Status", less "Unpostable Documents to Reject Status" (both on GMF0740, page 5), plus "Raw Documents to Reject Status" (GMF3740, page 2).

2. Add the Reject Block Proof Record document counts for all files "from GMF errors" on the SCF1151. The total should equal the count of Error Documents to Reject Status on page 9 of the GMF0840.

3. Add the Reject Block Proof Record document counts for all files "from ERS errors" on SCF1151. The total should equal the sum of the "Returns Analysis Records Added" to the Workable and Unworkable Suspense Inventories and the "Records Suspended" and "Duplicate Block Records moved to Suspense" from the Error Inventory, all shown on the Error Resolution Inventory Control Report, ERS1747. (See IRM Figure 3.17.30-112).

(1) The SCCF is limited to 150 control records per SCCF module.

3.17.30.10.5.1 (01-01-2010)

Action for amounts Greater than 150

(1) Whenever the 150th control record tries to post in batch processing, the block is printed on the Invalid Transcript, SCF0743, with Transcript Code MX.

1. Enter an 8–2 SCFAJ adjustment as the 150th control record to delete the block in the next posting run. (See IRM Figure 3.17.30-114).



2. The block will then be deleted from the SCCF and printed on the next Invalid Transcript with Transcript Code 82. (See IRM Figure 3.17.30-115).



3. If an on-line SCCF adjustment tries to post the 150th record with other than From-To Code 8–2, the control record will display as an Invalid Transcript with code MX. Any on-line adjustment with From-To Code 8–2 posts to the SCCF immediately and deletes the module from the SCCF during the next SCF05 posting run for printing on SCF0743 as invalid with Transcript Code (TC) 82.

(2) Any module that deleted from the SCCF because of the overflow condition should be manually consolidated and reestablished on the SCCF with Command Code SCFAJ.

1. Combine any control records with the same From Code, To Code, Posting Date, and cross-reference DLN (if any). Add the document count and money amount of these records to form single control records. If this does not sufficiently reduce the number of records, other consolidations may be necessary.

2. Reestablish the record on the SCCF using Command Code SCFAJ. Enter each control record, providing as much documentation as possible in the Remarks field, including cross-reference DLNs and the cycles of the original postings. (See IRM Figure 3.17.30-116).

(1) End of Year procedures is issued annually on the Submission Processing Website and/or by memorandum. These procedures should be followed to ensure that all purged records from GMF, ERS, and GUF get properly accounted for and controlled on the SCCF. Access to EOY Documents, Checklists, and Schedules and reference documents is identified below.

• https://irssource.web.irs.gov/WI/Lists/SP/All.aspx

• EOY Document - Mainline Volume 2 - Error Resolution System (ERS Batch) section has a list of forms that will require actions through the ERS00 conversion process.

• GMF/SCF EOY Purge/Reformat Conversion Handout - has a complete list of forms that will require actions through either GMF00 or ERS00 conversion processing.

(2) The EOY Conversion occurs in three phases.

1. Phase 1 - Final GMF/ERS/SCF in Current Processing Year

2. Phase 2 - Conversion/Purge Processing GMF/ERS/SCF/GUF

3. Phase 3 - Start-up Processing - First Mainline in New Processing Year

(1) This Phase represents final GMF/ERS/SCF in the current processing year. Special emphasis should be placed on decreasing and keeping minimal inventory volumes prior to the end of the processing year.

(2) To prepare for the EOY the following is recommended:

• Remove ERS lag early in December

• Encourage Input Correction to order GMF loop register on a shortened turnaround time to ensure closures

• Emphasis should be placed on reducing on resolving SCCF aged cases in all inventories

(3) In addition to the normal reports that is necessary for balancing the final SCCF string of the current year, other reports should also be utilized for use in balancing and verifying the conversion output. It is strongly recommended that Data Control keep these final reports and registers with their conversion reports since they’re in current year format and cannot be worked by Input Correction.

• GMF0903 - GMF0944/0945/0946

• GMF0940 Run Control

• GMF1001 - GMF - 1041/042/1043 (IMF)

• GMF1002 - GMF - 1041/1042/1043 (Non-IMF)

• GMF1040 Run Control

• GMF1101 - GMF1143/1147/1141/1148/1149

• GMF1140 Run Control

(4) For the GMF Register, all loops should be requested in the GMF1080 for the final running of GMF and again for conversion processing. See special instructions for preparing the GMF1180 in the GMF/SCF EOY Purge/Reformat Conversion Handout.

(5) Final ERS will run as an abbreviated string that will include only jobs that must update suspense activities and good tape records that affect the SCCF database. The specific instructions for the mainframe processing requirements can be found in the ERS section of the EOY Mainline Document Volume.

1. The balancing of Error and Reject inventories to SCCF will include volumes from all reports except ERS1747. ERS1747 will not be available until after conversion processing is completed.

2. Complete a partial balance of the Error/Reject inventories to SCCF prior to requesting final GMF15 TEP. This abbreviated string includes ERS05/ERS06/ERS08/ERS83/ERS71/ERS75/ERS77/ERS93/ERS96. For specifics concerning these runs and ERS01 and ERS03, refer to the EOY Mainline document.

(6) For the Final GUF, verify that the purge indicator is previously set for all Master Files in the final running of the year for GUF5149. Review GUF5149 for unmatched records. Balance the output as normal for TEP release.

(7) The Final SCCF should be balanced as normal and file/tape input verification is imperative to ensure that all transactional records, on outstanding files and/or tapes from the current processing year, is processed through GMF successfully.

1. Verify the master control record files/tapes in GMF0440 and the good block proof record files/tapes in GMF0140.

2. Balance all SCCF run controls and verify inputs to SCF01.

3. Ensure GUF files (GUF5201 to GMF01 and GUF5104 to SCF01) get processed in the final SCF run stream.

(8) It is imperative that Data Control Units and their respective Enterprise Computing Centers partner in identifying all outstanding tapes/files prior to final mainline.

(1) At the end of each processing year, special GMF, ERS, and GUF programs is generated to purge and/or reformat end-of-year inventories in BOBs, ERS Errors and Rejects, GMF Errors and Rejects, and Unpostables. There is several terms associated with Conversion/Purge processing.

• Reformat - Format change required to the sub-program to allow processing in the new year

• No reformat - No change required to the sub-program, record remains in current format

• Purge - Record must be removed from the inventory where it currently resides and then reinput, except IRP, it is deleted and not reinput

(2) End-of-Year programs always run at the end of the calendar year but can also run at other times during the year, when major changes occur in certain processing programs.

(3) The exact scheduling of end-of-year runs is determined by the Enterprise Computing Centers. Often a series of purge runs must be completed within a specific time frame, such as over a holiday weekend, requiring Accounting support outside their normal tour of duty.

(4) The ERS00 Conversion program executes the necessary reformatting and purging of ERS records for compatibility with the programming updates scheduled for the upcoming year. The ERS 00 provides a list of actual records processed through conversion and the ERS0049 reports the actual volumes input and output. Listed below is the ERS Run Controls.

• ERS0040 - ERS Conversion Record List

• ERS0049 - ERS Conversion Run Control

• ERS0149 - ERS Run Control Report

• ERS0649 - ERS Transaction File

• ERS0749 - ERS Unworkable File Run Control

• ERS1349 - ERS Workable File Run Control

(5) Identified below are the ERS conversion verifications/validation requirements:

1. ERS0040 - verify that any program records that scheduled for the purge have the "P" in the purge indicator column of the ERS0040.

2. Purged items - Verify status on SCCF database once the SCCF Purge runs is completed, locate the documents and reinput.

(6) ERS0049, Input Controls Validation as part of the ERS conversion is listed below:

1. ERS0049 total count for ERR-REC-UNWK-OLD-FILE (IN) plus (+) ERR-REC-WORK-OLD-FILE (IN) equals (=) the total count listed on the last running of ERS1349 under ERS-CTRL-REC-WORK-FILE WORKABLE CONTROL RECORDS minus (-) the total count on the last running of ERS0649 under the Output Controls and listed as ERS-TRANS-FILE TRANSACTION RECORDS.

2. ERS0049 total count for ERS-UNWK-FILE (IN) equals (=) the total count for ERS-UNWK-FILE UNWORKABLE SUSPENSE RECORDS on the last running of ERS0749.

3. Verify the ERS0049 input control totals match the output control totals (minus purged items if applicable).

(7) Following verification/validation of the ERS00 by Data Control, the computing center will complete the remaining ERS jobs under the new year's programs, including the database runs and ERS17. Output totals from the ERS1747 run control will be used to complete the ERROR/Reject balance that previously started when the final GMF/ERS/SCF generated. This ERS Error and Reject inventory balance must be completed to verify that the ERS conversion was successful and that all databases is accurate.

(8) For balancing discrepancies between Error/Reject Inventories and SCCF, the following information may help with the reconciliation:

1. Identify the forms categorized as reformat, no reformat, and purge within the inventories that require conversion processing (ERS error and reject inventories). Refer to the EOY Document Mainline Volume 2 - Error Resolution System (ERS Batch) section which has a list of forms that will require actions through the ERS00 conversion process.

2. There will be variances in counts if records previously purged for reinput because the updates (from and to codes 3-0) have not processed to SCCF. The ERS1701 from the ERS conversion processing will be input to SCF01 during the SCCF Purge processing. This input file will update the inventories in the database and will account for the activities on the SCF1141 Adjustment List.

3. There may be variances in the counts associated with suspense activities (items moving to suspense). This variance will occur when ERS items have specific reject condition codes that automatically move the documents through Error to Rejects.

(9) The GMF00 CONVERSION program executes the necessary reformatting and purging of GMF records (GMF10 errors, GMF11 rejects, GMF09 BOBs) for compatibility with the programming updates scheduled for the upcoming year. GMF0040 reports the volume processed through conversion and lists the activity volume (reformat, no reformat, purge). Identified below is the GMF Run Controls:

• GMF0040 - GMF Conversion Run Control

• GMF0940 - BOB File Documents in BOB Blocks

• GMF1040 - Error Doc File Error Documents

• GMF1140 - Reject Master File Reject Documents

(10) Refer to the Purge/Reformat Conversion Handout to identify the forms that is being reformatted, not reformatted, and purged in GMF.

(11) Identified below are the GMF conversion verification/validation requirements.

(12) Balance and validate the GMF0040 Conversion Run Control to the final year end reports for GMF0940/GMF1040/GMF1140.

1. Validate correct files input for conversion. The counts in the section labeled "Input Control Counts Balancing" and the column labeled "Counts Generated in Display Run" for each of the GMF0940, GMF1040, and GMF1140 should equal (=) counts reported on the GMF0040 in the section labeled "Input Control Counts Balancing" and the column labeled "Counts Generated in Prior Run".

2. If these counts differ, immediately notify the designated Enterprise Computing Center and request Operations to verify the input file.

(13) Balance and validate the GMF0040 input/output counts as follows:

1. The counts in the section labeled "Input Control Count Balancing Section" under the column labeled "Counts Generated in Prior Run" should equal (=) the column labeled "Counts Generated in This Display Run."

2. This balancing validates the output file as correct and ensures inventories get correctly formatted under the new programming.

(14) Verify the GMF0040 counts to the conversion output for GMF0940/GMF1040/GMF1140.

1. THE GMF0040 counts in the section labeled "Input Control Count Section" and the column labeled "Counts Generated in Prior Run" should equal (=) the counts generated in the section labeled "Input Control Counts Balancing" and column "Counts Generated in Display Run" column of each of the conversion run control reports for GMF0940, GMF1040 and GMF1140.

2. This balancing verifies that the GMF09, GMF10 and GMF11 runs processed with the correct input file from GMF00 conversion.

(15) Validate Reformat, No Reformat, and Purge counts.

1. Validate the number of Reformat, No Reformat, and Purge documents according to the form and program list in the GMF/SCF Purge/Reformat Conversion Handout.

2. If forms scheduled to be purged that were in the inventory at the time of conversion, verify the purged counts to the GMF1043 and GMF1143 by actual program number.

(16) Verify GMF0040 Output control counts.

1. Compare output totals and verify that all disposition (purged) records sent an adjustment to the SCCF.

2. Verify all disposition (purged) documents is accounted for on the SCF1141, Adjustment Control Record List. Error = (3-2), Reject = (4-2) and B) = (1-2).

(17) In GMF0040-IRP, verify all IRP is listed in the Purge column.

(18) If there is discrepancies in count balances encountered during the GMF conversion verification/validation, from IRM 3.17.30.10.8 (12) through (17) above, research by specific program in the GMF10 and GMF11 summary reports to identify the variance.

1. Report discrepancies that may be processing problem related to the Enterprise Computing Center.

2. On rare occasions records may be dropped from processing during conversion, not attributable to computing center operational error.

3. Data Control identifies, researches, recovers, and resolves these records.

(19) Balancing the SCF Purge string is similar to daily balancing routine, verify worksheet totals and inventory balances; also verify all from and to dates and cycle information.

(20) Schedule the ERS1701 (from conversion) to be processed through the SCF Purge string. If the ERS1701 is not processed it may still be processed during the first running of SCF programs in the new processing year.

(21) The following purged inventory from and to codes will be listed on the SCF1141, Adjustment List:

• Items purged in GMF00

• Items purged in ERS00

• Items automatically move to ERS Suspense (from and to code 3-4 to Rejects)

(22) SCCF Database activity during conversion is described in this subsection. GMF conversion processing moves error and reject records to manual status (3-0 and/or 4-0) and deletes IRP errors on the SCCF database (3-2). Occasionally, a non-remittance program may be purged without subsequent processing with a (from-to code) to code of 2.

1. The purged records is on the SCF1141, Adjustment CRL, with From-To codes of 3-0 and 4-0 and require reinput processing. IRP error deletes is reflected in the From-To Codes 3-2.

2. The Intermediate Error File-Total Documents on page 8 of GMF0840 plus the Raw Documents to GMF Error Status on page 5 of GMF0740, and the SCF0742, Control File Summaries, should decrease by the count reflected on the SCF1141.

3. The Intermediate Reject Files-Total Documents on page 9 of GMF0840 plus the Raw Documents to Reject Status on page 5 of GMF0740 and the SC Reject balances on the SCF0742, Control File Summaries, should decrease by the count reflected on the SCF1141.

4. The manual SCCF balances on the SCF0742, Summaries, get increased by the count of the From-To Codes 3-0 and 4-0 records on the SCF1141.

(23) The majority of GUF Conversion is completed systemically. Verify the output controls to validate the purge process and to ensure no records dropped or removed from the database during conversion processing. Manual balancing will also identify when system error messages mistakenly overrode during mainframe processing. Refer to EOY Document Volume II which provides information concerning the specific conversion routines. Listed below is the GUF Controls:

• GUF0049 = Conversion Run Control

• GUF8649 = Conversion Run Control

• GUF8749 = Conversion Run Control

• GUF8849 = Conversion Run Control

• GUF5140 = List of Unmatched Database and Transaction File Records

• GUF5149 = Extract Run Control Report

• GUF1349 = GUF Run Control

• GUF1549 = GUF Run Control

(24) Listed below is GUF conversion verification/validation requirements.

1. GUF0049 to GUF1549 - Input Section - Validate the Data Records Read by GUF00 and Database Records Per GUF15 match and equal the Output Section labeled Records Written to GUF1501 File on the last running of GUF1549.

2. GUF0049 to GUF1349 - Input Section - Validate the Data Records Read by GUF00 and Data Records per GUF13 match and equal the total reported in the Output Files Section labeled Cumulative-RPS-610-FIle-Out on the last running of GUF1349.

(25) Listed below is the verification/balancing of the GUF86-RUN-CONTROL-REPORT.

1. Compare the GUF5101 UPDATED-SC-UP-TRANS-FILE output control count (from the final running of GUF5149 RUN-CONTROL-REPORT) should equal the GUF5101 INPUT RECORD COUNT which is listed under the Control Counts Total column of GUF8649 in the record count and amounts. The GUF5101 OUTPUT RECORD COUNT (GUF8649 listing should equal the GUF5101 INPUT RECORD COUNT, less the total of Dropped Cases and their amounts (GUF8649 listing).

2. All record counts and PJ amounts on the GUF8649 should be zero except under the "CAWR" heading, since records for the other Master Files should have purged by GUF51.

3. The LIST OF DROPPED CASES on the GUF8649 should be used to reinput a deleted document as raw data, unless the case has already closed (refer to GUF5740 CLOSED-UNPOSTABLE-REGISTER listing), using the TIN as the identifying key.

(26) The GUF8649 does not always display the list of dropped records. If there is dropped record counts and/or amounts on the GUF8649, but nothing specific listed on the dropped cases list, request a filecracker extract from the computing center to identify the taxpayer and transaction information for reinput processing.

(27) Review the GUF8649 to identify any dropped records that will require reinput processing. If the dropped record count is excessive, contact the Enterprise Computing Center to initiate research to identify why the records dropped.

(28) The GUF8749 verification/balancing is presented below.

1. Verify the GUF5301 Input and Output record counts and amounts is the same.

2. If they differ, the difference will be listed in the deleted section by Master File. The specific taxpayer data will be listed in the dropped records section if any records get deleted.

3. Verify that the Control counts, SC Unpostable on the GUF8749 equal the count listed on the final GUF5149 in the section labeled GUF Area SC Unpostable Rec Control Counts, Records Fetched with Purge Indicator, plus the Output Control Counts (GUF5101), Updated SC UP TRANS File, plus (GUF 5102) Transaction Records Purged.

(29) To perform GUF8849 verification/balancing, the Data Records Extracted from GUF-Area listed in the Input Section of the GUF8849 should equal the counts on the final GUF 5149 in the section labeled GUF-Area SC Unpostable Rec Control Counts, Records Fetched with Purge Indicator, plus the Output Control counts (GUF5101) Updated SC UP TRANS File, plus the (GUF 5102) Transaction Records Purged.

(1) Start-up processing is scheduled by the computing centers and a HUB site is designated to balance the initial mainline of the new year with updated programming. All tapes and/or files that is held awaiting mainframe programming changes is scheduled and processed during the first mainline of the new year. Depending on the calendar dates and the cut-off period, multiple files/tapes may be included in the first running. For example, there is multiple tapes/files for Lockbox and ISRP RPS due to ongoing deposit processing. It is crucial that all sites are aware of outstanding tapes/files and verify inputs to GMF01, GMF04, and SCF01, to ensure all data is processed timely.

(2) Report anomalies associated with programming updates to prevent recurrences and negative downstream impact. The following action(s) is recommended to ensure programming deficiencies get identified and reported quickly:

• Verify all outstanding tapes/files is processed through the first GMF/SCF mainline.

• Be aware of all programming changes that directly impact mainline processing.

• Review and analyze all SCF error codes that could be associated with EOY programming changes.

• Review and analyze all SCF Invalid Transcripts that could be associated with EOY programming changes.

• Report all anomalies immediately to ECC via the Help Desk.

(1) When a block of documents on the transaction tape is in error, the block is identified for possible deletion by the Tape Edit Processing (TEP) run, GMF15. Records can be deleted in TEP three different ways.

1. If the SCCF identifies an inconsistency between the transaction Good Block Proof Record and the existing SCCF file, a delete record is generated onto the on-line delete file, where Data Controls will determine if the block should be deleted. A printed Block Delete Request List, SCF0341, may be used in conjunction with the SCFDL file to control the SCCF deletes. (See IRM Figure 3.17.30-117).



2. If Data Controls identifies a block that should not be allowed to post, a record is added manually to the on-line delete file.

3. The TEP program may identify and delete a block due to incorrect tape record length, format, or record balance. These records get deleted without being processed through the on-line delete file.

(2) The Delete Source Code identifies the method of deletion and determines the effect the delete will have on the SCCF.

1. TEP generated deletes, not created from the delete file, is coded with Delete Source Code C.

2. Delete records created by the SCCF by an Invalid Transcript has Delete Source Code S. These records get worked by Data Controls, who will determine whether the block should actually be deleted.

3. Any other block that is determined to be invalid or incorrect may be deleted by adding the record to the on-line delete file. This record has Delete Source Code M or S, depending on whether the Good Block Proof Record should be automatically reversed on the SCCF.

(1) Each Good Block Proof Record that does not post to the SCCF in SCF03 is listed on the Block Delete Request List (SCF0341) and placed on the on-line delete file.

(2) Enter Command Code SCFDL to access the delete file. (See IRM Figure 3.17.30-118). The response to SCFDL is a display of the daily delete records on the file.

3.17.30.11.2.3 (01-01-2010)

Command Code SCFDLA

(1) To add a record to the delete file, enter Command Code SCFDL with definer A. The response to SCFDLA is a twelve-line, X -filled screen. (See IRM Figure 3.17.30-119).

(2) Complete the record by overlaying the Xs in the format provided. Figure 3.17.30-120 shows the completed record.

1. MFC is the Master File code (1 = IMF, 2 = BMF, 3 = EPMF, 5 = IRP, 6 = NMF).

2. Enter the block DLN with year digit (no hyphens).

3. Enter the Delete Source Code (DSC). Enter code M if a 5–0 control record should post to the SCCF, or code S if the SCCF status should not be updated.

4. Enter the fourteen-number tape sequence number from the Tape Control Record List (SCF1151). Not applicable for NMF.

5. The Alpha Block Control (ABC) is optional.

(3) Up to 12 delete records may be added on one screen at a time. When all delete records entered, use the down arrow key to get to the bottom line of the screen and immediately transmit. If all records have entered in the proper format, they get added to the delete file in DLN sequence by Master File. (See IRM Figure 3.17.30-121).

1. If more than 12 deletion records need to be added, then a new SCFDLA screen request must be entered. The SCFDLA program does not have multiple pages.

2. Terminal response will be Request Completed. It is recommended that the user access SCFDL after transmitting and receiving the Request Completed message, to ensure the coding is kept in the screen.

   Note: Failure to transmit from the correct position at the bottom of the SCFDLA screen as instructed above may result in a loss of the data that is entered.

(4) If any added record has not been entered in the correct format, an error message is displayed, with the invalid field highlighted.

1. The entire screen is kept until the error is corrected or the invalid record blanked out and the screen is successfully transmitted.

2. The action code, Master File code, block DLN, delete source code, and tape sequence number is validity checked.

(5) If the format is valid but a mistake is made in entering a record, either because the block should not be deleted or because a field is previously transcribed incorrectly, overlay the generated "A" with an "R" and the delete request will not be processed. Then use SCFDLA to re-enter any record that should be deleted.

(6) Until the file is released for processing to the Tape Edit Processing (TEP), any code may be overlaid with another code or changed to a blank.

(1) Any block that is identified by the TEP programs as invalid or inconsistent will be deleted automatically by the TEP.

(2) These generated deletes carry a source code C, which is printed on the Deleted Records List and the Adjustment CRL.

(3) See IRM 3.17.30.12.6 for a description of the two-alpha delete codes, which explain the reason for the generated delete.

(4) TEP deletes may be generated from corrected unpostables from the GUF.

(5) For corrected unpostables, no special procedures is required, unless the Deleted Records List does not show all the required information. If unable to identify the records being deleted, contact the ECC, via IRworks, to obtain a complete copy of the deleted record from the transaction tape.

(1) A deletion is the removal by ECC of an entire block of data from a Transaction Tape. After a transaction is under ECC Control it is either "Posted", "Rejected" or sent "Unpostable". Control is kept under the original DLN module on the SCCF, and the pre-journalized amounts must be added to SC suspense accounts and subtracted from the ECC Suspense accounts. Requests for ECC-MTB deletes from the Submission Processing Campuses will not be honored under in the daily processing environment.

3.17.30.11.4.2 (01-01-2012)

Enterprise Computing Center (ECC) Acceptance Voucher Summaries

(1) On a daily and weekly basis, the ECC-MTB Trans Release File Acceptance Voucher Summaries, Run 793-01, will be available on Control-D. Verify the totals against that cycle's SCF1151, TCRL, and GMF1545, TEP, totals. (See IRM Figure 3.17.30-122).

(2) All AAVs will be available on Control-D for viewing. The weekly summary report will reflect all cycle deletes by reel and Work Group Number. The AAVs must be balanced daily for IMF and weekly for all Master Files to the correct GMF1545 cycle. Data Adjustment Vouchers (DAV) will have all items deleted at MCC (PVS) that require recovery action by the Campus.

1. Adjust the CRL in green if SPC requested, blue when ECC initiated, and/or attach a copy according to local procedures.

2. Forward the voucher to RRACS for adjusting journal entry.

3. If needed, prepare Form 2275 to get the documents for input from Perfection Branch or Files.

4. Input SCFAJ with From-To Code 5–0 and Source Code D to place the deleted block back into suspense if the documents will be reinput with Form 3893.

5. For NPJ IDRS records, no SCCF adjustment is necessary. Route a copy of the listing to the IDRS coordinator, who will determine if reinput is necessary.

6. An attachment to the acceptance voucher also lists any Submission Processing Campus file that may have returned as unprocessable.

7. Whenever the acceptance voucher shows that a file has not processed, contact the Help Desk to ensure that a recovery effort has initiated. The initial contact from ECC may have been received by telephone.

(1) IDRS deletes is handled much the same way as regular TEP deletes except that many deleted IDRS transactions must be reinput through IDRS. The documents get obtained from Files through the IDRS transaction records.

(2) Determine which transactions can be input through mainline (ISRP). The following transactions may be input only through IDRS, regardless of the method of original input:

1. Entity Changes for the IMF, BMF, and EPMF (Doc Codes 50, 53, 63, 80, 81).

   Exception: EPMF Module Change Form 2363B

2. Dual Debit/Credit Transfer for IMF and BMF (Doc. Code 34)

3. Delinquent Accounts and Returns for BMF (Doc. Codes 14 and 49)

4. Document Codes 78

   Exception: IRP

(3) Document Codes 77 except the following:

1. T/C 460 extension of time for filing

2. Transaction Codes 023, 024, 053, and 120.

3.17.30.11.5.1 (01-01-2010)

Form 3893 for Reinput Documents

(1) Reinput the documents which can be processed through mainline. Prepare Form 3893. It is completed the same way as for other tape deletes except as below: (See IRM Figure 3.17.30-123).

1. Box 1—Blank

2. Box 3—Blank

3. After preparing Form 3893, attach it to the first document and route to Data Conversion to be reinput, or leave boxes 1 and 3 blank and route to Batching.

4. Edit the documents for proper input. The documents normally will not go to Returns Analysis.

5. Route the documents which cannot be reinput through mainline to the IDRS Control Staff, the originating function, or an area designated by the Control Staff.

(1) Receipt and Control will provide a listing of manual adjustments made to the ISR0551, Deposit Summary Report. (See IRM Figure 3.17.30-124).

(2) Confirm the manual adjustments made to the RPS Remittance Recap. and the Form 215-A.

1. If the adjusted monies are not on the RPS Remittance Recap, the block(s) will need to be deleted from TEP.

2. Research the DLN(s) through CC: SCFTR to determine if the block(s) processed through GMF and SCCF.

3. If the DLN(s) have gone to good tape on SCCF, the block(s) will need to be deleted from TEP.

(3) Lockbox processing sites implemented Electronic Check Presentation (ECP) in December 2010. Electronic images of the checks are processed through ECP instead of paper. Occasionally, a duplicate image will be processed. ECP will be able to delete the duplicate transaction from its totals, but the transaction will be included in the ISRP totals. BFS will send an E-mail to the Campus ECP Administrator with a copy to Headquarters. The Campus Administrator will contact the Data Control function with the duplicate transaction information (DLN, TIN, MFT, tax period, dollar amount). The Campus Administrator will coordinate with the Data Control and Dishonored Check functions to make the decision whether to delete the transaction from the TEP.

1. If the decision is made to delete the duplicate transaction from the TEP, delete the duplicate transaction using IDRS CC SCFDLA.

2. If the TEP with the duplicate transaction is released, prepare Form 2424 to reverse the duplicate credit on the taxpayer's account. Debit the taxpayer's account and credit the correct tax class account.

(1) Instructions for reading the Deleted Records List is included in IRM 3.17.30.12.6.

(2) Each block that is deleted in TEP generates a control record for the SCCF. If this control record is not error coded on the CRL or appearing on the invalid transcripts, the SCCF module will have been affected in two ways.

1. The Action Delete Status Indicator is turned on, thus preventing any new Block Proof Records from posting.

2. If the Delete Source Code (lower right corner) is C or M, the control record will include a From-To Code 5–0, placing the deleted documents back into manual status.

3. See IRM 3.17.30.12.6 for instructions on reading the Deleted Records List.

3.17.30.11.7.1 (01-01-2010)

Deleted Blocks

(1) If the entire block must be voided, reinput, or renumbered, notify Input Correction to take the necessary action for any documents still in error or reject status.

(2) Pull the required documents according to local procedures

1. If the documents still being processed is valid and need not be deleted, input Command Code SCFAJ with From-To Code 8–7 to turn off the ADSI. Then pull only the documents that deleted and reinput with Form 3893. (See IRM Figure 3.17.30-125).

2. If the block should be voided, input an SCFAJ adjustment for the documents on the Deleted Records list using To Code 2. The From Code will match the current status on the SCCF.

(3) If the block must be renumbered, assign the new DLN using the Off-Line DLN Generation Application in BBTS.

1. Notify Input Correction to delete the items still open in the Error or Reject inventory. If ERS code 640 is used, a From-To code of 3–0 or 4–0 will post to the SCCF database.

2. For ERS, Action Code 660 is entered with Command Code RJECT. At Submission Processing Campus option ERS deletes may be entered on the terminal by Data Controls personnel. When all documents have deleted from rejects, adjust the SCCF as necessary and establish the new DLN with From-To Code 0–0.

(1) When it is determined that any documents need re-entered into the system, prepare a Form 3893, Re-Entry Document Control.

1. Any editing on the document must be done with a red pencil. Be sure that the first document in the block has the proper received date.

2. Attach the Form 3893 to the first document of the block to be used as a header document.

3. Route to the Batching function. Receipt and Control Branch for processing.

4. For certain priority documents, such as PRP, Congressional, and some subsequent payments, hand carry the block to Data Conversion Branch for Transcription.

3.17.30.11.8.1 (11-27-2020)

Form 3893 Instructions

(1) Only one Form 3893 should be prepared when several documents is being re-entered from the same block, unless the documents is reprocessable.

(2) One Form 3893 should be prepared for each return re-entered as reprocessable.

(3) Form 3893 is prepared as follows: (See IRM Figure 3.17.30-126).

1. Box 1—Alpha/Number Block Control Number—Leave blank if routing to Batching in the Receipt and Control Branch. If routing directly to Data Conversion, enter the designated alpha.

2. Box 2—Document Locator Number—Enter the eleven-digit block DLN. The complete DLN may be entered, but only eleven numbers are transcribed into the block header.

3. Box 3—Enter the batch number if routed directly to Data Conversion.

4. Box 4—Document Count—Enter the number of documents attached to Form 3893.

5. Box 5—Credit Amount—Enter the amount of the credit transaction. If more than one document, enter the sum of the credit amounts. Amounts may be from payment transactions, transfer documents, or adjustments.

6. Box 6—Debit Amount—Enter the total amount of the debits. This box must be blank if a credit amount is present. Debit amounts may be present only with document code 24, 45, 48, 51, 54, 58, and 87.

(4) Box 7—Transaction code

1. Enter only when block header transaction code is required.

2. For IRP, enter the Account Type Code, followed by the Record Identification Code (F or G) followed by the Payer Count. See IRM 3.10.8 for details.

Document Code	Transaction Code on Document	Transaction Code in block Header
45	840	840
53	090–092	090
51, 52	Transfer in	370
30	984, 986	984, 986
80	000, 012, 013, 014, 016	000, 010
81	000, 016

(5) Box 8—Trans Date

1. Always enter the received date for Form 1040-ES and Form 1040-C.

2. Enter received date for returns received after the tax period due date.

(6) Box 9—Header MFT Code—Enter only when required.

Document Code	Document MFT	Header MFT
17, 18, 19, 24, 34, 45, 47, 48, 51, 52, 54, 58, 87	05, 06, 15	05, 06, 15
IMF tax class 4	29	29
Form W–3G	32, 98	32, 98
Form 1096	69	69
RRPS Payments	Various	Same as document
IRP 74	74	74

(7) Box 10—Secondary Amount—Enter the secondary transaction amount when required. If you fail to enter a secondary amount on Form 3893 when the amount is present on the document, a block-out-of-balance condition will be created.

(8) Box 11—Re-entry Source Code—Mark one box as shown.

1. Mark "R" for Reprocessable if the return has already posted to the Master File. Also, complete box 19.

2. Mark "N" for Nullified if the reinput document is previously an unpostable. Also, complete box 18.

3. Mark "4" for Reinput if the reinput block/document has neither posted nor unposted at the Master File. The "4" should always be used when issuing and processing a new DLN. Also, complete box 18. When processing a new DLN, mark "Other" in box 18 and write "New DLN."

(9) Box 12—DLN Year digit—This box must be entered.

1. Enter the 14th digit of the DLN from the source document.

2. If the year digit is not shown on the document, determine the correct year from the DLN color or from other information on the document.

DLN Color	Year Digit
Green	0 or 5
Purple	1 or 6
Red	2 or 7
Black or brown	3 or 8
Blue	4 or 9

(10) Box 13—RRPS Return Indicator—This box should be marked only when a matching RRPS payment has already posted, with the same DLN except for the inflated Julian date, to the same TIN, MFT, and tax period. Never mark this box for reprocessables.

(11) Box 14—Remarks—Enter any other information needed to clarify the reason for re-entry or to preserve a proper audit trail. For deletes, enter the cycle of the delete action.

(12) Box 15—Process as Remittance or Non-Remittance—Mark the Remittance box if the document or block has money. Payment vouchers and accounting transactions with doc codes 24, 45, 48, 51, 58, and 87 is Remittance documents. Green-rocker the payment originally input as RRPS if the payment is now being processed with the document and mark Remittance. Returns with green-rockered payments is Remittance unless the payment has already posted to the taxpayer's account; if the green-rockered payment has already posted or if the payment is removed for separate processing, edit out the "green" money with red pencil and mark the Non-Remittance box. Adjustment documents is Non-Remittance even though header amounts may be present in box 5, 6, or 10. Reprocessable returns is always Non-Remittance.

(13) Box 16—Serial Number—Enter the DLN serial number(s) of the documents being re-entered. For an entire block or multiple documents, enter the range of serial numbers, such as 00–49 or the specific serial numbers.

(14) Box 17—Preparer information—Enter your name and phone number and the current date. Also mark the correct originating organization.

(15) Box 18—Reinput document—If box 11 is "N" or "4", mark the proper box.

(16) Box 19—Reprocessable return—If R is marked on item 11, enter the reason that the posted return is being reprocessed.

(1) Before requesting the daily Tape Edit Processing (TEP), verify the tape inputs in GMF0140. You will need the following reports:

1. IPS01119

2. ISR0140

3. GUF5149

4. RPS0740