Download the RT&E Skip Calculator from the Submission Processing web page, under Business Results Measures/Refund Timeliness and Error Rate.

Before using the skip calculator, you will need two pieces of information:

Do NOT use X because that is a summary count which includes prior years and those should not be included in the sample.

Enter the total into the Skip Calculator. Send a copy of the calculator to the designated Headquarters Analyst by the 20th calendar day of the month preceding the sample month.

The Headquarter analyst will consolidate the information from all centers and forward the skip intervals to the GMF Schedulers at the Martinsburg and Tennessee Computing Centers.

The calculator uses a standard sample size of 195 for each center. This was established by Statistic of Income (SOI).

When there is a change in Mail Stop Number, IDRS Employee Number used for MFTRA requests, or MFTRA Bulkdata Password, you must inform the Headquarters analyst prior to the month in which the change is effective.

GMF 1609 selects current year paper IMF returns using the skip intervals provided to the GMF Schedulers at ECC-MTB (formerly MCC) and ECC-MEM (formerly TCC), See IRM 3.0.275.6.3.1. The run generates a Form 4251, Return Chargeout, for each return that was selected for review.

GMF 1609 runs each weekday of each week and selects the sample from the records of the returns that went to good tape the previous business day.

Contact your local Operations Branch and arrange to have the Forms 4251 forwarded to the Improvement Team rather than to the Files function. See Document 6209, IRS Processing Codes and Information, for GMF Processing Cycles.

One employee in each Submission Processing Improvement Team must obtain a TRS90/Bulkdata password in order for the team to receive the generated GMF files, Notice Review Processing System (NRPS) NOT Runs, and MFTRA prints for either the Notice Error Measure or Refund Timeliness and Error Measure.

To receive the password, submit a Form 5081, Information Systems Users Registration/Change Request, following these instructions:

If replacing the current user of TRS90/Bulkdata request, take the following steps once the password is received:

GMF 1610 is an output file from GMF 1609 and provides a listing of data from each sampled return. Use the data from GMF 1610 to account for each sample return and to determine Data Conversion's use of Entity Index File during data input.

This report is available on Control-D and should be printed each week on Wednesday. This report will assist the Improvement Team reviewer or clerk in managing the RT&E inventory. It will also provide EIF access information for the reviewer.

Data from GMF 1610 is loaded into the SMART database each week:

Download GMF 1610 each week from Control-D and print a copy. You will use GMF 1610 to control sample cases and to review the entity for each sample case.

GMF 1649 is an output file from GMF 1609. It provides a summary of the week's sample:

Review GMF 1649 in Control-D each week to verify that sampling has been completed. If you identify any sample problems, open an ITAMS ticket following local procedures and inform the Refund Timeliness and Error Rate Headquarters analyst.

The Improvement Team employee(s) should prepare folders for each week's sample. The folders should be clearly labeled with the extract ( month-week) and the cycle number. The GMF 1610 listing should be placed in the folder awaiting the returns and MFTRA.

You will receive Forms 4251 each week. Make sure that they are in DLN order. Place the forms in the folder for that week's extract.

You will receive MFTRA transcripts approximately two weeks after the GMF 1609 sample run. Sort the transcripts into DLN order and place them in the suspense folder for that cycle's extract. See Document 6209, IRS Processing Codes and Information, for GMF Processing Cycles.

When you receive the extract's returns from Files, check to make sure they are in DLN order. Associate the MFTRA transcripts with the returns. Check the MFTRA and returns against the GMF 1610 listing to verify that all documents and transcripts have been received.

If a return is not date stamped with an IRS received date use the Batch Block Tracking System (BBTS) to find the IRS received date (This instruction does not apply to ITIN cases, See IRM 3.0.275.6.4.3. Sites are not required to date stamp current year returns received prior to April 23rd.

If BBTS research indicates "no record found" for the DLN you entered, research the DLN in the BBTS History File through the intranet using the following instructions.

Taxpayer instructions and IRS procedures regarding filing and processing Forms W-7 (Application for IRS ITIN) were revised effective with the 2004 filing season. The filer sends both the Form(s) W-7 application and the Form 1040/A/EZ together to the IRS. The ITIN application process must be completed before the processing of the tax return can be started. The tax return must still be processed within 40 days of receipt to be considered timely.

For 2007 filing season, filers will be instructed to mail their ITIN Application (and tax return) to Austin.

Use the ITIN database to find the IRS received date if the return is not date stamped.

Request Form(s) W-7 as appropriate if unsure of the IRS received date.

Exclude ITIN cases from the sample that have had correspondence. Check for any working trails left on the return.

If the case was not excluded from review, enter the literal " W-7" in the Case Number Field.

See Exhibit 3.0.275-8. to identify all timeliness errors using the Who, What, and Why codes.

If a sample case's Days Diff is greater than 40 days, try to determine what caused the delay. Research BBTS and the Campus Control File (using IDRS Command Code SCFTR) for these cases to identify delays in normal pipeline processing.

If the untimely refund was due to an Unpostable return, research the reason for delay and enter the appropriate Who/What/Why codes.

If an untimely refund was delayed by other post-processing functions, enter the appropriate Timeliness Who/What/Why codes.

If an untimely refund was delayed due to Master File resequencing, code the return timeliness as Z, 42, ZZ.

If you determine that processing pipeline functions are causing delayed refunds, consider a special review to determine the causes.

Identify all Accuracy errors using the Who, What, and Why codes. See Exhibit 3.0.275-8.

Perfect cases are identified by a "P" code in the SMART database Perfect field. If the "P" code is entered, you cannot enter Accuracy or Timeliness Who, What, or Why codes.

Refund Errors must be coded in the following priority:

The purpose of the Entity Index File processing is to save key strokes during Distribution Input System/Remittance Processing System (DIS/RPS) data entry if the name and address information already exists on the Master File.

The Entity Index File is created from entity data extracted from the Business Master File, the Employee Plans Master File and the Individual Master File, as well as Social Security Administration data. The Entity Program determines whether the operator must transcribe the name and address data.

The GMF 1610 file contains the following information about the use of the National Account Profile (NAP) and Entity Index File (EIF) by Data Conversion:

The NAP/EIF Access Indicator and NAP/EIF Response Indicator are loaded to the SMART database from GMF 1610 for each sample case. Use this information to focus on the root causes of entity discrepancies, which are the most frequent IRS process errors identified in the Refund Error Rate program. The NAP/EIF access and response codes will also help you identify systemic errors caused by Entity Index File. Such as: If short/intermediate/long has been generated and is different than what is shown on IMFOL and corrections could have been input/made then, See IRM 3.0.275.2 and See IRM 3.0.275.3. See Exhibit 3.0.275-9 for a table of Access Indicators and Response Codes.

The following is a list of Entity Codes.

Record all significant discrepancies in the database.

You will identify minor entity discrepancies in the Professionalism section of the SMART database. See Exhibit 3.0.275-8 for a list of Professionalism Who/What/Why codes. See IRM 3.0.275.2 Entity Review for Letter Error, Refund Error, and Notice Error Review and See IRM 3.0.275.3 Address Review for Letter Error, Refund Error and Notice Error Review.

If you identify a significant entity discrepancy and the taxpayer requested a Direct Deposit refund, check the Direct Deposit Indicator on the IMFOL screen to determine whether or not the refund was deposited ( See Exhibit 3.0.275-10 for Direct Deposit Codes).

Route cases that require entity corrections to the Entity Team following local procedures.

Math verify each sample return to validate the refund amounts shown on the return as submitted and as posted to Master File. Identify IRS mistakes, regardless of dollar amount, using the Accuracy Who/What/Why codes in the SMART database.

Verify total wages shown on the return against Form(s) W-2, using no tolerance other than a $1.00 difference as a result of rounding.

Verify withholding shown on the return against Form(s) W-2, using no tolerance other than a $1.00 difference as a result of rounding. If the taxpayer claims more withholding than is supported by Forms W-2, consider the withholding not supported and record an error.

Review each return to determine if the taxpayer requested a direct deposit of their refund. If a direct deposit was requested, review the IMFOL screen to determine whether or not the request was honored (Command Code IMFOB with definer T will show the bank account number and routing transit number if entered by ISRP). See Exhibit 3.0.275-10 for a listing of EFT and Direct Deposit Reject Reason Codes.

Review the IMFOL screen for refund offsets (Transaction Code 898 for other agency offsets and Transaction Code 826 for IRS offset).

If refund interest was generated because the received date was not input or edited, or the Received Date was input or edited incorrectly, code as an Accuracy error.

If you do not receive sample returns after your second request, code Accuracy as Who/What/Why Z, 42, ZZ. The case will not be included in calculations of Refund Error Rate.

If Form(s) W-2 have been detached from a return, code Accuracy as Who/What/Why Z, 42, ZZ. The case will not be included in calculations of Refund Error Rate.

Only record the received date and refund date when detached W-2 cases are coded Who/What/Why Z, 42, ZZ and a refund was issued.

Do not code for Accuracy or Timeliness if the sample case is a duplicate filing or if the refund from the sample case is frozen due to a subsequent duplicate filing on the same SSN. Code Accuracy Z, 42, ZZ and leave the Refund Method Code and Refund Received Date blank.

If a non-compute return results in a refund, code Accuracy and Timeliness as you would for a normal refund return. If the non-compute return does not result in a refund, do not code for either Accuracy or Timeliness. Enter Accuracy Why Code "ZZ" and leave the Refund Method Code and Refund Date fields blank. Delete any entry in the Received Date field.

If you discover that a refund was issued but should have been partially or fully credited to the following tax year, review the data entry to determine if Data Conversion input the correct credit elect amount. If not, code Accuracy Who/What/Why accordingly. If Data Conversion input the correct credit elect information, code Accuracy Who/What "J 32" (Other Systemic/Credit Elect) with the appropriate Accuracy Why code.

The following National Timeliness Reports are available:

The following National Error Rate Reports are available:

The following Timeliness Reports by Campus are available:

The following Error Rate Reports by Campus are available:

We use the TC 846 refund date to determine a review month. For example, all cases with refunds issued in March are considered March cases.

The review month cut-off date is the 22nd day of the month, following the end of the sample month.

You will thoroughly examine each sampled notice using the guidelines in this IRM. You will record the results of your case analysis in the SMART database, using the NER DCI. The sampled records consist of notices as identified on the IMF and BMF controls (RUN460–3E and 160–3D) provided by Information Technology Services.

You will review all actions taken on the sample case. Use the appropriate IDRS Command Codes to research the account(s) involved.

Review sample cases after all IDRS input action is complete. You must review the actual input against case documentation to ensure all actions were appropriately taken.

If an error is found during the Improvement Team review of a Notice Review case, Improvement Team will charge an Accuracy or Professionalism error (depending on the type of error) if the Operation made the decision not to pull the return to complete the On Line Notice Review (OLNR) and a return was required for that review.

If the return was not pulled because of the Notice Review Processing System (NRPS) determination by Headquarters or the return is unserviceable (files did not have return, e.g., return destroyed, Federal Record Center (FRC), or held in another area), Improvement Team will charge a systemic Accuracy or systemic Professionalism error if the return was required for that review. Improvement Team will notify Notice Review of any trends that are identified.

For source documents sent to Files, prepare a document request following local procedures. If the charge-out indicates it is charged out to another area contact the area to get a copy of the document. If the charge-out indicates document not in file, review IDRS to see if the DLN was re-numbered. If after thorough research you cannot locate the document and at least 10 days have passed, input a second request using CC ESTABD "V." Use Command Code RTVUE or BRTVU if the document is not received within 15 days or Files charge-out information indicates the document has been destroyed. (Use Command Code RTVUE or BRTVU as the return information for case review.)

Follow the general review guidelines in IRM 3.14.1, IMF Notice Review, and IRM 3.14.2, BMF Notice Review, when reviewing the entity portion of a notice.

For all notices, determine if the issue of the notice is appropriate. See Document 6209, IRS Processing Codes and Information, for a list of notices and their conditions.

Review the notice thoroughly to ensure that the notice text is correct. If necessary, check the notice text against its PRP or FSP. Determine if the notice correctly describes the state of the taxpayer's account.

Review IDRS, RTVUE, BRTVU, relevant IRMs, and other research sources to ensure a thorough review of the notice. For ELF returns TRDBV will reflect what the taxpayer input using E-file.

Always check the notice text against the PRP when one of the following conditions exist:

Review the "Submission Processing Notice Systemic Error Chart" for correct coding instructions for all systemic errors. This chart is located on the Submission Processing Web Site, Balanced Measures, Notice Error Rate. For reporting Systemic Problems, See IRM 3.0.275.1.8.

Handle the case based on the guidelines established by the area to which the case is being referred.

Provide defect feedback to the appropriate functional areas. Whenever possible, recommend solutions to eliminate future defects.

Provide taxpayer error information to the Public Affairs Officer.

Review correspondence issued to taxpayers as part of your case review when attached to the return. Correspondence must provide a correct and complete response to all taxpayer and IRS issues. Correspondence must resolve the taxpayer's issue, request additional information from the taxpayer, and/or notify the taxpayer that information has been requested from outside the IRS. For more information on correspondence requirements, see IRM 21.3.3, Incoming and Outgoing Correspondence/Letter.

The overall impact of extra Submission Processing Dual Notices being sampled is being addressed through the Request for Information Services (RIS) process. Until this programming change is completed, it is acceptable for you to manually reduce your sample of Submission Processing Dual Notices if the Improvement Team Manager determines that the number of Dual Notices received in your sample would create a hardship to review and enter into the database. Generally, the number of excess Dual Notices should be greater than five per cycle to be considered a hardship. If this is the case, you may manually reduce the Dual Notices in your sample according to the following procedure:

If you remove Dual Notices from your sample, every Dual Notice in your sample must have an equal chance of being removed. You must perform the reduction up front, rather than by attrition (i.e., do not just eliminate the Dual Notices for which you don't receive the return).

To open the Business Results Measures Home Page: http://balmeas.enterprise.irs.gov .

Click on Notice Error Rate Tab.

Notice Rate Home Page is shown.
http://balmeas.enterprise.irs.gov/NoticeError/NoticeErrorHome.asp.

Click on DCI Input Form key and select either "Search Record," "New Record," or "Exit."

Follow the "Business Results Measures for Submission Processing Functions, Job Aid," (Catalog Number 37697B, Training 6804-701), page 5-5, steps 1-22. To obtain a copy of the Job Aid go to: http://coursebooks.enterprise.irs.gov/ on the left hand side select Business Measures which will bring up the training 6804-701, click on the training number.

The following Exhibits provide Who, What, Where, and EXPOE Codes. See Exhibit 3.0.275-14. See Exhibit 3.0.275-15. See Exhibit 3.0.275-16. See Exhibit 3.0.275-17.

To ensure that your monthly error rate (calculated from your sample) represents the campus actual error rate (in the overall population of notices generated), you must enter as many cases as possible before the report deadline for the sample month. Cycles that will be included in the month's report are provided in the yearly Cycle Chart, ( See Exhibit 3.0.275-12) for this reason, it is important that all campuses remain current on the cycles you are coding.

If the source document (return) is not secured prior to the two month data cut-off deadline, Submission Processing notice cases can still be input to the SMART database without the source document (return) and after the cut-off deadline, however, these cases will not be included in the official Notice Error Rate calculations because they do not represent a full review of the notice, especially the Entity area. It is likely that several Submission Processing cases sampled each month will be excluded from official error rate calculations due to the non-receipt of the return. However, information on these notices will still be available on the SMART database to capture other types of errors that can be identified without the return (e.g., systemic errors) and will be available for diagnostic purposes.

The Notice Error Rate measure considers only SMART database Who Codes of "7" (Computer Program/Hardware-Not EIF, or SCRIPS), "9" (IRM/Program Requirement Package/PRP/Forms Instructions),"25" (EIF or Systemic Problems), and "26" (SCRIPTS/ELF/MAG Tape), to be true systemic errors. Systemic errors are distinguished from errors that have a human cause.

SMART database Who Codes "23" (Area Office),"28" (Post Office), "29" (FMS/RFC), "31" (Lockbox etc..), "34" (Other Government Agency), and "35" (Other Accounts Management/Compliance/campus (SC) unknown), are excluded from the Notice Error Rate calculations, since the error is not caused by the IRS Submission Processing.

All other NER Who Codes not included in 1 and 2 above, are included as "non-systemic" in Notice Error Rate calculations on the SMART Database.

You will identify each defect you find as either a Professionalism or an Accuracy error. Professionalism errors are relatively minor and do not represent inaccurate information being given to the taxpayer. For example, incorrect spacing or punctuation would be considered Professionalism errors. These errors are not inaccuracies, but they do not present a professional product to the public. In contrast, Accuracy errors do represent inaccurate information being given to the taxpayer.

See Exhibit 3.0.275-19 for Professionalism coding chart. This chart also contains when accuracy errors should be charged.

The following are examples of Accuracy errors. This list is not inclusive.

The official definition of Refund Interest is the amount of refund interest paid per $1 million of current year IMF and BMF refunds issued in the original settlement cycle.

The measure uses a rolling 12–month cumulative figure that looks at current year IMF and BMF original settlement refunds only. The figure that is reported represents the total refund interest divided by the quotient of the total refund dollars issued divided by $1 million. Combat Zone returns for IMF are excluded from this measure.

The refund interest data comes from the weekly IMF 703–76–13 and the BMF 161-06-13 reports, which counts only interest paid on current year IMF and BMF returns that refunded in the original settlement cycle. These files are used to obtain the total refunds and interest paid for each cycle to compute the Interest Per Million for local use.

In an effort to obtain more accurate reporting of IMF and BMF Refund Interest costs, a request to change the program was submitted. Beginning 10/01/02, the change took into account refund reversals and refund interest reversals.

The IMF 703-71-XX and the BMF 161-01-XX (xx indicates the campus file location number) reports are accessed from Control-D. These files are transmitted to the campuses each week and contain one record for each original settlement refund with interest posted in the current cycle to a tax module for the pertinent tax period. These files can be loaded into an Excel spreadsheet and the data can be manipulated and sorted to extract a sample for review. The reports show the:

Goals are computed based on past history data, including reversal data. We will continue to monitor Refund Interest data and if necessary, further revise the goals accordingly.

Data is captured systemically, and 100% of the returns with interest are included.

Data is available weekly on the SMART database, and reported monthly to management.

Improvement Teams must coordinate with their local Refund Interest Coordinator to address high amounts of refund interest paid.

Sites See IRM 3.0.275.1.10"SMART Database Cut-Off Dates and Report Information for all Business Results Measures," specifically (6) and (7).

Coordinators should develop strategies for preventing refund interest, i.e., meeting Project Literal for the Control Data Analysis Project (PCD), using Interest Jeopardy Reports, and developing local procedures. Share new "best practices" /local procedures/strategies with the HQ Refund Interest analyst. The HQ analyst will then share with the other sites. Also, if coordinators find a procedural problem or an area causing large amounts of interest, these issues must reported to the HQ analyst.

Once a month, a validity check is done by HQ on the refund interest paid computations.

All Refund Interest Paid reports can be accessed on Control-D. See the Control-D Job Aid link: http://win.web.irs.gov/am03jax/ControlD/CTDWA%20Job%20Aid.doc