Form Handbook 361 Handbook 361 Unemployment Insurance Data Validation Program

Unemployment Insurance Data Validation Program

DV Handbook 2008

Unemployment Insurance Data Validation Program

OMB: 1205-0431

⚠️ Notice: This form may be outdated. More recent filings and information on OMB 1205-0431 can be found here:

Document [pdf]

Download: pdf | pdf

UI TAX
EMPLOYER CONTRIBUTIONS
DATA VALIDATION HANDBOOK

MAY 15, 2008

OMB No: 1205-0431
OMB Expiration Date: 05/31/2008
Response Time: 550 hours.

OMB Burden Statement: These reporting instructions have been approved under the
Paperwork Reduction Act of 1995. Persons are not required to respond to this collection of
information unless it displays a valid OMB control number. Public reporting burden for this
collection of information includes the time for reviewing instructions, searching existing data
sources, gathering and maintaining the data needed, and completing and reviewing the
collection of information. Submission is required to obtain or retain benefits under SSA
303(a)(6). Send comments regarding this burden estimate or any other aspect of this
collection of information, including suggestions for reducing this burden to the U. S.
Department of Labor, Employment and Training Administration, Office of Workforce
Security, 200 Constitution Avenue, NW, Room S-4522, Washington, D.C. 20210.

UI Tax Validation Handbook

Estimated Average

5/7/07

CONTENTS

Chapter

Page

INTRODUCTION .............................................................................................................. I-1
A.

OBJECTIVES ....................... .............................................................................. I-1

DATA ERRORS IDENTIFIED THROUGH VALIDATION ........................... I-3

DATA SOURCES FOR FEDERAL REPORTING AND VALIDATION ........ I-4

BASIC VALIDATION APPROACH ................................................................. I-5

RECONSTRUCTING FEDERAL REPORT ITEMS ........................................ I-7

HANDBOOK OVERVIEW ................................................................................ I-9

WALK THROUGH OF DATA VALIDATION METHODOLOGY .............. I-11

MODULE 1−REPORT VALIDATION ........................................................................... 1-1
A.

PROCEDURES .................................................................................................. 1-2

EXAMPLES........................................................................................................ 1-4

MODULE 2−DATA ELEMENT VALIDATION ............................................................ 2-1
MODULE 2.1−FILE INTEGRITY VALIDATION ......................................................... 2-2
A.

PROCEDURES .................................................................................................. 2-2

EXAMPLES ....................................................................................................... 2-4

MODULE 2.2−RANGE VALIDATION .......................................................................... 2-8
A.

PROCEDURES .................................................................................................. 2-9

EXAMPLES ..................................................................................................... 2-11

MODULE 3 − FEDERAL DEFINITIONS AND STATE-SPECIFIC
VALIDATION INSTRUCTIONS ............................................................. 3-i

UI Tax Validation Handbook

iii

5/7/07

CONTENTS (continued)
Chapter

Page

MODULE 4 − TPS QUALITY SAMPLE VALIDATION .............................................. 4-1
A.

PROCEDURES .................................................................................................. 4-1

EXAMPLES ....................................................................................................... 4-3

MODULE 5 − WAGE ITEM VALIDATION .................................................................. 5-1
A.

PROCEDURES .................................................................................................. 5-2

EXAMPLES ....................................................................................................... 5-4

APPENDIX A:

REPORT VALIDATION FILE SPECIFICATIONS ................. A.1

PART I:
PART II:

TERMINOLOGY AND TIMELINES ........................................ A.2
POPULATION TABLE SPECIFICATIONS ........................... A.10

APPENDIX B:

INDEPENDENT COUNT ........................................................... B.1

APPENDIX C:

REPORT VALIDATION SUMMARY REPORTS ................... C.1

APPENDIX D:

FIV WORKSHEETS ................................................................... D.1

APPENDIX E:

DUPLICATE DETECTION CRITERIA .................................... E.1

APPENDIX F:

RECORD LAYOUTS .................................................................. F.1

UI Tax Validation Handbook

5/7/07

TABLES

Table

Page
INTRODUCTION

TYPES AND USES OF ETA 581 DATA ............................................................. I-1

VARIATIONS IN VALIDATION METHODOLOGIES BASED ON
STATE APPROACHES TO REPORTING AND RECONSTRUCTION ............ I-6

ETA 581 REPORT, BY TRANSACTION POPULATION ................................. I-8

MODULE 1
1.1

SUMMARY OF REPORT VALIDATION POPULATION FILES .................... 1-1

1.2

OVERVIEW OF MODULE 1 (FIGURE 1.5) ...................................................... 1-9

MODULE 2
2.1 OVERVIEW OF MODULE 2.1 (FIGURE 2.3) ................................................... 2-6
2.2

STATUS DETERMINATION REASON CODES ............................................ 2-11

2.3 RANGE VALIDATION CRITERIA ................................................................. 2-12

MODULE 3
3.1

DATA ELEMENT VALIDATION STEPS AND SUBSTEPS .......................... 3-iii

3.2

RELEVANT DATA ELEMENT VALIDATION STEPS,
BY POPULATION .............................................................................................. 3-iv

UI Tax Validation Handbook

5/7/07

LIST OF FIGURES

Figure

Page
INTRODUCTION

FORM ETA 581 ......................................................................................................... I-2

OVERVIEW OF UI TAX DATA VALIDATION METHODOLOGY .................. I-13

MODULE 1
1.1

POPULATION 3 RECORD LAYOUT .................................................................... 1-5

1.2

POPULATION 3 SAMPLE EXTRACT FILE ......................................................... 1-6

1.3

POPULATION 3 SUBPOPULATION 3.1 DISPLAY
AFTER IMPORT INTO SUN-BASED DV SOFTWARE ....................................... 1-7

1.4

POPULATION 3 REPORT VALIDATION SUMMARY ....................................... 1-8

1.5

REPORT VALIDATION ........................................................................................ 1-10

MODULE 2
2.1

EXAMPLE OF FIV SAMPLES WORKSHEET ...................................................... 2-4

2.2

SAMPLE PAGE FROM MODULE 3 ...................................................................... 2-5

2.3

FILE INTEGRITY VALIDATION PROCEDURES ............................................... 2-7

MODULE 4
4.1

SAMPLE TPS COMMENTS SCREEN ................................................................... 4-3

MODULE 5
5.1

WAGE ITEM VALIDATION WORKSHEET ......................................................... 5-5

UI Tax Validation Handbook

5/7/07

INTRODUCTION
A. OBJECTIVES
States regularly report to the U.S. Department of Labor (DOL) under the
Unemployment Insurance Required Reports (UIRR) system. In particular, states
document their performance in collecting UI employer contributions (taxes) and
employer reports on the Employment and Training Administration (ETA) 581
report entitled “Contribution Operations.”
Data from the ETA 581 report are used for three critical purposes: (1)
allocation of UI administrative funding based on state workload, (2) performance
measurement to ensure the quality of state UI program operations, and (3)
calculation of state and national economic statistics. Table A summarizes the
types and uses of the data. Figure A displays the ETA 581 report.

TABLE A
TYPES AND USES OF ETA 581 DATA

Data Type
Active Employers

Funding/
Workload

Performance/Tax
Performance System
(TPS) Computed
Measures

Economic
Statistics

Report Filing

Status Determinations

Accounts Receivable

Field Audits

Wage Items

Because ETA 581 data have these critical uses, it is essential that states
report their activities accurately and uniformly. Data validation measures the
accuracy of state reporting on employer contribution activities. Two principles
underlie a comprehensive data validation process:

UI Tax Validation Handbook

I-1

5/7/07

INTRODUCTION
FIGURE A
FORM ETA 581

UI Tax Validation Handbook

I-2

5/7/07

INTRODUCTION
1.

If data are collected, they should be valid and usable.

Given the high degree of automation of UI systems, it is feasible and
cost effective to validate most report cells.

States conduct the validation themselves and report the results to ETA. This
handbook provides detailed validation instructions for each state. ETA also
provides states with a Sun-based data validation software application (referred to
as the Sun-based system in UIPL 22-05) to use in conducting the validation.
States are required to validate reported data every third year, except for data
elements used to calculate the Government Performance and Results Act (GPRA)
measures. GPRA data are validated annually. The “validation year” will
coincide with the State Quality Service Plan (SQSP) performance year.
Validations of any reporting period during the twelve-month period beginning
April 1 and ending March 31 will be considered part of the validation year. The
SQSP is the vehicle through which states submit plans to implement validation or
to revalidate failed items.

B. DATA ERRORS IDENTIFIED THROUGH VALIDATION
Systematic errors and random errors are the two major types of data error in
federal UIRR reports. Systematic errors involve faulty design or execution of
reporting programs. Random errors involve judgment and input errors.
Reporting system errors are always systematic, while errors stemming from
human judgment can be either systematic or random. Both systematic and
random errors must be addressed in the validation design.

•

Systematic errors are addressed through validation of the reporting
programs that states use to create federal reports. Systematic errors
tend to be constant and fall into one of three categories: 1) too many
transactions (overcounts), 2) too few transactions (undercounts), or
3) transactions which are misclassified. Systematic human errors
occur when staff are using incorrect definitions or procedures. For
example, a reporting unit may establish its own definition for a data
element that conflicts with the federal definition (this can happen
deliberately or inadvertently). Systematic errors are the most
serious because they occur repeatedly. They are also the easiest to
detect and correct. Systematic errors do not need to be assessed
very frequently, and each system error only needs to be corrected
once. A one-time adjustment in a retrieval code or calculation

UI Tax Validation Handbook

I-3

5/7/07

INTRODUCTION
specification, or staff retraining on a corrected definition or
procedure, will usually correct systematic errors.
•

Random errors are more variable. They include problems such as
input errors or judgment errors such as misunderstanding or
misapplying Federal definitions. In general, random errors occur
intermittently. For example, a few data entry errors may occur even
when most information is entered correctly. Correcting one error
does not ensure that similar errors will not occur in the future.

Consistent and accurate reporting requires both good data and accurate
systems for reporting the data. Data validation and Tax Performance System
(TPS) reviews together test whether data are accurately posted to the state
employer contributions system and reported correctly on the ETA 581.

C. DATA SOURCES FOR FEDERAL REPORTING AND VALIDATION
States use different methods to prepare the ETA 581 report. Some states
produce the Federal reports directly from the employer contributions database.
Computer programs scan the entire database to select, classify, and count
transactions. Other states produce a database extract or statistical file as
transactions are processed, essentially keeping a running count of items to be
tabulated for the report. Still other states use a combination of these methods.
The basic approach to data validation is the same no matter how the report is
developed — states reconstruct the transactions that should have been reported
and do so using standard national criteria.
The validation methodology is flexible in accommodating the different
approaches used by states. However, validation is most effective when validation
data are produced directly from the employer contributions database. For cost
reasons and to minimize changes in data over time, some states prefer to use
daily, weekly, or monthly statistical extract files instead. When extract files are
used, other types of system errors may occur. Reportable transactions may be
improperly excluded from the employer master file. Furthermore, the statistical
file may contain corrupt data. The statistical file is not used as part of the daily
tax system and, therefore, errors may not be detected and corrected through
routine agency business.
The only way to test for these problems is to independently reconstruct or
query the employer master file. States that produce validation data from the same
statistical extract files used to produce the ETA 581, rather than directly from the

UI Tax Validation Handbook

I-4

5/7/07

INTRODUCTION
database, must ensure that the extract files contain all the appropriate employer
transactions and statuses. The way to do this is to recreate the logic used to
produce the ETA 581. This handbook includes a validation tool, “independent
count validation,” specifically for this purpose.1
Table B outlines variations in the validation methodology, based on typical
state approaches to ETA 581 reporting and data validation reconstruction. To
determine the specific validation methodology to be implemented, the state
validator or federal representative should identify the state’s ETA 581 report
source and validation reconstruction source for each population to be validated.

D. BASIC VALIDATION APPROACH
The basic approach used in data validation is to reconstruct the numbers that
should have been reported on the ETA 581. Because state UI records are highly
automated, states can develop computer programs that extract from electronic
databases all transactions or statuses that should have been counted on the report.
Automation reduces the burden on validators and state information systems (IS)
staff as they extract records from state files, assemble those records for analysis,
and assess validation results.
Once transactions and statuses are extracted, they are subjected to a series of
“logic rules.” These rules test the accuracy of the reconstructed data, assuring that
states have used the most definitive source of information and have adhered to
Federal definitions. After it is determined that the extract data meet the logic
rules, the data are used to produce validation counts that are compared to what the
state has reported. If the validation counts match what was reported, within a plus
or minus 2 percent tolerance, then the reporting system is judged valid.
States conduct validation using web-based software which runs on DOL Sun
computers in state UI offices. Each computer has an established interface with
DOL for report transmission, and the national office, the appropriate regional
office, and each state can retrieve reported numbers from this shared data base.

There is no way to accurately reconstruct the reported count when the statistical file
contains transactions that are no longer present in the database (e.g., when it includes status
determinations deleted from the main database after a corrected status determination is made for
the same employer).

UI Tax Validation Handbook

I-5

5/7/07

Count

Yes

DRE

Count

ETA 581

Statistical
file

Database

Statistical
file

Database

Source

TABLE B

DRE

Must create a
daily extract

Daily

DRE

Daily

Snapshot

DRE

Program
Type

Snapshot

Timing

Daily

Statistical
file

I-6

Yes

Statistical
file

Daily

Yes

Snapshot

Timing

Independent
Count
Required

Snapshot

Database

Source

Data Validation

VARIATIONS IN VALIDATION METHODOLOGIES BASED ON STATE
APPROACHES TO REPORTING AND RECONSTRUCTION

Snapshot is of the last day of the reporting period.
Detail Record Extract
Not Available

UI Tax Validation Handbook

NOTE:
DRE =
NA
=

DRE

Count

Scenario

Program
Type

Transactions
Overwritten on
Database

INTRODUCTION

Yes

Source
Documentation
Review
Required

5/7/07

Cannot reconstruct from
database. Must change
reporting process to Scenario 5.

No alternative validation
source. Cannot reconstruct
from the database. Not
thorough validation.

Since transactions are not
overwritten, states should be
able to do Scenario 2 instead.

Reporting and validation are
the same program.
Independent count may mirror
that program.

Database is only reconstruction
source. There could be changes
in transaction characteristics
(but will find all transactions).

Best scenario because
comparing snapshots eliminates
timing discrepancies

Comments

INTRODUCTION
Data validation provides a reconstruction or audit trail to support the counts
and classifications of transactions that were submitted on the ETA 581 report.
Through this audit trail, the state proves that its UIRR data have been correctly
counted and reported. For example, if a state reports 5,000 reimbursable
employers at the end of the quarter, then the state must create a file listing all
5,000 employers as well as relevant characteristics such as the Employer Account
Number (EAN), employer type, liability met threshold date, number of liable
quarters, and wages in each of those quarters. Analysis of these characteristics
can assure validators that the file contains 5,000 correctly classified employers.
The reported number is thus proved to be valid.

E. RECONSTRUCTING FEDERAL REPORT ITEMS
There are 50 ETA 581 report items to validate.2 A single employer account
transaction or status may be counted in several different ETA 581 report items.
For example, a contributions report that is filed on time is counted in two items
for the current report quarter (timely reports and secured reports) and in one item
in the following report quarter (resolved reports).
A general principle of the validation design is to streamline the validation
process as much as possible. Transactions and statuses are analyzed only once,
even if they appear in multiple items. The streamlining is accomplished by
classifying them into mutually exclusive groups, which match to one or more
items on the federal report. Specifically, there are five types of employer
transactions or statuses (populations), which are further divided into 46 mutually
exclusive groups (subpopulations). All validation counts are built from these
subpopulations. The five populations are: (1) Active Employers, (2) Report
Filing, (3) Status Determinations, (4) Accounts Receivable, and (5) Field Audits.
Table C lists the ETA 581 populations and subpopulations that are
reconstructed and the number of report items validated by each population. It
also describes the dimensions used to divide populations into subpopulations.

Wage items processed (item 5 on the ETA 581) are validated but through a less
comprehensive process. The ETA 581 wage item count is not reconstructed.

UI Tax Validation Handbook

I-7

5/7/07

INTRODUCTION
TABLE C
ETA 581 REPORT, BY TRANSACTION POPULATION

Population

ETA 581
Line
Numbers

Dimensions Used to
Create Subpopulations

Number
of Report
Items

Number of
Subpopulations

1. Active
Employers

101

Employer status:
∃ contributory
∃ reimbursing

2. Report Filing

201

Timing of report receipt and
resolution:
∃ timely
∃ secured within the quarter due
∃ resolved within two quarters

3. Status
Determinations

301

Type of status determination:
∃ new
∃ successor
∃ inactive
∃ terminated
Time lapse of the determination

4. Accounts
Receivable

401
402
403
404

Type of receivable processing:
∃ amounts established
∃ liquidated
∃ declared uncollectible
∃ removed from the report
∃ outstanding debt

5. Field Audits

501
502

Employer size:
∃ small
∃ large
Audit result:
∃ change
∃ no change

Wage Items
Processed

101

N/A

UI Tax Validation Handbook

I-8

5/7/07

INTRODUCTION
F. HANDBOOK OVERVIEW
To determine the extent to which reported data are accurate and meet federal
reporting definitions, four separate validation procedures or Αmodules≅ have been
developed. These modules include various tools to use in validating the quantity and
quality of federally reported data. The modules and accompanying appendices are
outlined below.

•

Module 1—Report Validation (RV)

Module 1 describes how to validate that state ETA 581 reporting programs
are functioning correctly. The Sun-based software systematically processes
reconstruction files and compares the count in each federal report item to the
count in the corresponding subpopulation.
The validator examines
transactions that were rejected by the software as invalid and determines if it
is necessary to regenerate or reload the validation files.
•

Module 2—Data Element Validation (DEV)

Module 2 describes how to validate that the data elements used in report
validation are correct. Two tests are conducted as part of DEV:
(2.1)

File Integrity Validation (FIV) checks that the correct data
were extracted from the database to build the reconstruction
file. The validator examines small samples drawn from each
subpopulation.

(2.2)

Range Validation checks whether characteristics associated
with a transaction are in the correct range for the particular
population and subpopulation in which the transaction has been
placed.

•

Module 3—State-Specific Data Element Validation Instructions

Module 3 provides the state-specific instructions that the validator uses in FIV
and range validation. Module 3 documents the system screens that display the
data to be validated as well as the rules that must be applied to each data element
to determine its accuracy. State definitions or procedures which impact
validation are also documented to help state and federal staff interpret the
validation results and improve procedures.

UI Tax Validation Handbook

I-9

5/7/07

INTRODUCTION
•

Module 4—TPS Validation

Module 4 determines whether the state’s TPS acceptance samples were
selected using appropriate methods. It is important to review the sampling
methodology used by the state. The quality reviews are a key indicator of the
state’s performance, and the results must be statistically valid.
•

Module 5—Wage Item Validation

This module explains how wage item counts are validated.
•

Appendix A—Report Validation File Specifications

Appendix A includes specifications for the five validation files that need to be
generated by the state. This appendix also includes tables that show the
relationship between each subpopulation and the corresponding federal report
line item(s). In addition, Appendix A provides information about timing issues
for each population.

•

Appendix B—Independent Count

Appendix B describes how to determine whether any transactions have been
excluded from an ETA 581 report item. These procedures are applicable to
states that create the ETA 581 from the same extract files used to generate the
reconstruction files.
•

Appendix C—Report Validation Summary Reports

Appendix C contains a sample RV summary report for each of the five
populations.
•

Appendix D—FIV Worksheets

Appendix D contains a sample FIV worksheet for each of the five
populations.
•

Appendix E—Duplication Detection Criteria

Appendix E provides the criteria used by validation software to identify
duplicate transactions or account statuses.

UI Tax Validation Handbook

I-10

5/7/07

INTRODUCTION
•

Appendix F—Record Layouts

Appendix F contains a validation file record layout for each of the five
populations.

G. WALK THROUGH OF DATA VALIDATION METHODOLOGY
This section provides IS and validation staff with a step by step walk through
of the data validation process using ETA 581 active employers as an example.3
Each step of the walk through references the handbook module in which that
aspect of the data validation process is described. Readers should review the
referenced modules for further information.
1) State IS staff generate the ETA 581 report from the state’s UI
employer database(s) or from statistical files of counts or detailed
records. The report item in the upper left corner of Figure B
represents the count of contributory and reimbursing employers
reported on the ETA 581.
At the same time, IS staff extract detailed records for the reported
transactions to reconstruct and provide an audit trail for the reported
count. (See Module 1.)
The state should generate the ETA 581 and the validation file (the
reconstructed “audit trail”) from the employer database(s) at the
same time. Ideally, to prevent inconsistencies due to timing, the
state would then immediately import the validation file into the
software so that FIV samples can be drawn and the state can
generate FIV supporting documentation (for example, query
screens) from the employer database(s).4
2) The DV software compares the reconstructed count with the
reported count. In this example, the validation screen shows the
detailed records for the three contributory employers reported on the
ETA 581.
3) The software selects a sample of two records per subpopulation and
displays them on the FIV worksheet. (See Module 2.) The
3

The validation file, sort file, and state-specific handbook have been modified slightly in
Exhibit I.5 for presentation purposes. Utah’s Tax Transcript screen and handbook are shown.
4

Given the highly automated nature of tax data validation, database screens are generally the
only supporting documentation needed. Therefore, this handbook refers to screens, rather than to
supporting documentation, throughout.

UI Tax Validation Handbook

I-11

5/7/07

INTRODUCTION
validator assembles the materials—Module 3, reconstruction files,
FIV worksheets, and screens—to be used during validation and for
review by DOL auditors.
4) The validator, following the “step” numbers in each column
heading on the FIV worksheet, tests the accuracy of the
reconstructed data using the state-specific instructions under the
corresponding step number in the state’s Module 3. The bottom
right portion of Figure B shows a page from Utah’s Module 3. (See
Module 2.)
5) Module 3 refers to state source documentation (usually query
screens) and to specific fields on the screens.
6) To complete FIV, the validator follows the rules for 2A
(contributory employer) in Module 3. The FIV rule for Step 2A
requires the validator to compare the employer type indicator on the
screen to the employer type indicator on the FIV worksheet. The
validator then selects either ‘PASS’ (if the two indicators match) or
‘FAIL’ on the worksheet.
The validator repeats the process for each data element on the
worksheet guided by the step numbers in each column heading.
(See Module 2.)

UI Tax Validation Handbook

I-12

5/7/07

Detail Record Extract
e.g. TPS status
determination file

UI Employer
Database

I-13

3 /9 5

U ta h

1 /9 6

2 /9 5

4 /9 5

Q tr

123

EAN

Tax
T r a n sc r ip t

$ 1 5 ,0 0 0

$ 1 6 ,0 0 0

$ 1 5 ,0 0 0

$ 1 2 ,0 0 0

T o ta l
W ages

SUBJ
TERM
EFFT
REOP

Figure B
Overview of UI Tax Data Validation Methodology

2. Reimbursing

End of Quarter Employers

1. Contributory

UI Tax Validation Handbook

Employer
Count

ETA 581

INTRODUCTION

$45

$48

$45

$36

C o n tr.
D ue

0 7 /0 1 /9 1
1 2 /3 1 /9 4
0 1 /0 1 /9 2
0 4 /0 1 /9 5

$45

$48

$45

$36

C o n tr.
P a id

A c tiv e
S ta tu s 1

5/7/07

REPORT VALIDATION

MODULE 1

MODULE 1−REPORT VALIDATION

The report validation process is used to determine the accuracy of the counts
reported in most of the items on the ETA 581 report. Five sets of files are
produced, which reconstruct the counts for the five types of employer
contributions populations that the state is validating. The report validation files
enable the validator to determine the accuracy of the ETA 581 report item counts.
The five report validation population files are listed in Table 1.1 on this page.
State IS staff are responsible for producing the reconstruction files according
to the tasks described in this module; the specifications in Appendices A, E, and
F; and the data element specifications in the state’s Module 3.

TABLE 1.1
SUMMARY OF REPORT VALIDATION POPULATION FILES
File Specification

Population

ETA 581 Line Number

Active employers

101

Report filing

201

Status determinations

301

Accounts receivable

401, 402, 403, 404

Field audits

UI Tax Validation Handbook

501, 502

1-1

5/7/07

REPORT VALIDATION

MODULE 1

A. PROCEDURES
Task 1:

Produce Five Report Validation Extract Files

State IS staff produce five report validation extract files−there is one extract
file for each of the five populations of UI contributions transactions and statuses.
IS staff should use the following specifications to prepare the five files:
1.

Record layouts (in Appendix F and also in the DV Software
Tutorial)

Population tables and timing specifications (Appendix A)

Duplicate Detection Criteria (Appendix E)

State Module 3

The extract file format is ASCII, comma delimited. See Figure 1.1 for an
example of a record layout. Data must be in the order listed in the record layouts.
The Data Type/Format column on the layouts indicates generic values for text
fields. The generic values must be followed by a dash and the state-specific
value. See Figure 1.2 for an example of an extract file.
The extract files are imported into the Sun-based DV software, which
processes each extract file and builds the subpopulations as specified in Appendix
A. The subpopulations are based on the unique types of transactions and statuses
that can occur and that can be reported on the federal reports. For example,
population 1, active employers, includes all employers who were active on the
last day of the quarter. The software assigns each record to a subpopulation
defined by unique combinations of characteristics such as employer status,
employer type, liability date, and termination date. See Figure 1.3 for a sample of
a validation file imported into the software.
It is essential that IS staff generate the validation files at the same time as the
ETA 581 to eliminate differences in data caused by changes in the employer
database(s) over time.1
Because the ETA 581 provides a “snapshot” of transactions and employer
statuses during a specific time period, the validation is intended to verify the
1

To the extent that states have a complete audit trail, timing problems should not affect the
reconstruction of transactions.
For example, states should maintain records of status
determinations even if the employer’s status changed in the same quarter. The validator then uses
these audit trails to verify that a transaction was correct at the time of reporting.

UI Tax Validation Handbook

1-2

5/7/07

REPORT VALIDATION

MODULE 1

status of transactions at the time the report was run, even if data later changed. It
is not efficient to compare a set of transactions or statuses captured at one point in
time with those captured at another point in time, because many discrepancies
will represent legitimate changes in a dynamic database, rather than systems
errors or faulty data. For example, an employer’s status can legitimately change
from active to inactive.
Task 2:

Import Extract Files

See the tutorial provided with the Sun-based DV software for detailed
instructions on importing the extract files.
Task 3:

Examine Error Reports and Reload Extracts If Necessary

When the extract files are loaded, the Sun-based DV software reads each
record to ensure that all fields are valid. Any records with invalid data, missing
mandatory data, or records which appear to be duplicates are rejected and an error
report is produced. See Figure 1.4 for a sample error report.
For example, the software produces an error report when data fields are not in
the format specified in the record layout (for example, dates in the wrong format
or text fields not preceded by one of the specified valid prefix values such as C
for contributory employers or R for reimbursing employers.) The record layouts
(see Appendix F of this handbook) specify the data formats which must be used
for the records to successfully import. The population tables in Appendix A
specify the valid values which must be present for transactions to be assigned to
subpopulations. The software also uses the duplicate detection criteria in
Appendix E to reject records which match the criteria for duplicates.
After reviewing any error reports that are generated, IS staff should
determine if the extracts need to be regenerated or reformatted and reloaded into
the Sun-based DV software.
Task 4:

Produce Employer History Screens for Sampled FIV Cases

States should, immediately after the Sun-based DV software generates the
FIV worksheets (discussed in Module 2), print all applicable employer history
screens for each sampled case, in the same order that the cases are sampled and
listed on validation worksheets. This concurrency ensures that the snapshot itself
is being validated. States may develop a batch program for this task.

UI Tax Validation Handbook

1-3

5/7/07

REPORT VALIDATION
Task 5:

MODULE 1

Produce Report Validation Summary

The Sun-based DV software calculates the validation count or dollar amount
for each subpopulation specified in Appendix A. The validation values are
compared to the corresponding reported values in the national UI database. The
software then calculates the difference between the validation and reported values
and also calculates an error rate. A reported value is considered valid and
“passes” report validation if the error rate falls within the established tolerance (∀
1% for data used in Government Performance and Results Act (GPRA) measures
and ∀ 2% for all others). 2 The software produces a summary report that displays
all of this information. This summary report is submitted to the UI national
office. Appendix C provides a sample RV summary for each population.
Task 6:

Conduct Independent Count (See Appendix B)

If a state uses the same detailed record extract file for reporting and
validation, the state must conduct an independent count. This is the reporting and
validation scenario described in row 3 of Table B in the handbook introduction.
Ideally, such files should not be used for validation. However, if they are used for
validation, states must conduct an independent count as described in Appendix B.

B. EXAMPLES
The following figures are examples of:
1.

Population 3 Record Layout (Figure 1.1)

Population 3 Sample Extract File (Figure 1.2)

Population 3 Subpopulation 3.1 Display after Import into Sun-based DV
Software (Figure 1.3)

Population 3 Report Validation Summary (Figure 1.4)

Overview of Report Validation (Table 1.2 and Figure 1.5)

The GPRA measures with a ∀ 1% tolerance are New Status Determination Timeliness (90
Days) and New Status Determination Timeliness (180 Days).

UI Tax Validation Handbook

1-4

5/7/07

EAN

Employer Type

Status Determ Type
Indicator

Time Lapse

UI Tax Validation Handbook

OBS

Field Name

No.

Step 12

Step 11A- D

Step 2A
Step 2B

Step 1A

Module 3 Reference

REPORT VALIDATION

1-5

Place a zero (0) in this
field. (Software generates
the time lapse)

Indicate status
determination type by
New, Successor,
Inactivation or
Termination.

Indicate whether the
employer type is
contributory or
reimbursable.

Employer Account
Number

Sequential number, start
at 1

Field Description

Number - 0

Text - N; S; I; T
(Required)

Text - C; R
(Required)

Number - 000000000
(Required)

Number - 00000000
(Required)

Data Type/Format

POPULATION 3 RECORD LAYOUT

FIGURE 1.1

INTEGER

CHAR (10)

CHAR (20)

INTEGER

DVWS

NOT NULL

5/7/07

Constraint

MODULE 1

POPULATION 3 SAMPLE EXTRACT FILE

FIGURE 1.2

UI Tax Validation Handbook

1-6

000000001,000000001,C-100,T-345,0,05/16/2003,03/31/2003,,,,,,,05/16/2003,20031021140204
000000002,000000002,C-800,I-306,0,05/08/2003,09/30/2002,,,,,,05/08/2003,,20031021140204
000000003,000000003,C-100,N-106,0,04/02/2003,12/09/2002,,04/02/2003,,,,,,20031021140204
000000004,000000004,C-100,I-306,0,06/13/2003,06/30/2002,,,,,,06/13/2003,,20031021140204
000000005,000000005,C-100,I-325,0,06/16/2003,03/31/2002,,,,,,06/16/2003,,20031021140204
000000006,000000006,C-100,N-101,0,04/02/2003,03/31/2003,,04/02/2003,,,,,,20031021140204
000000007,000000007,C-100,I-306,0,06/13/2003,03/31/2003,,,,,,06/13/2003,,20031021140204
000000008,000000008,C-040,S-186,0,04/03/2003,01/01/2003,,04/03/2003,,04/03/2003,000281498,,,20031021140204
000000009,000000009,C-040,I-370,0,04/03/2003,12/31/1997,,,,,,04/03/2003,,20031021140204
000000010,000000010,C-420,S-186,0,04/03/2003,07/01/2002,,04/03/2003,,04/03/2003,000149776,,,20031021140204
000000011,000000011,C-420,I-370,0,04/03/2003,12/31/1980,,,,,,04/03/2003,,20031021140204
000000012,000000012,C-130,S-186,0,04/03/2003,10/02/2002,,04/03/2003,,04/03/2003,000051455,,,20031021140204
000000013,000000013,C-130,I-370,0,04/03/2003,03/31/1971,,,,,,04/03/2003,,20031021140204
000000014,000000014,C-000,S-165,0,04/21/2003,01/01/2002,,04/21/2003,,04/21/2003,000283912,,,20031021140204
000000015,000000015,C-100,I-306,0,06/03/2003,09/30/2002,,,,,,06/03/2003,,20031021140204
000000016,000000016,C-100,S-161,0,04/08/2003,01/24/2003,,04/08/2003,,04/08/2003,000309296,,,20031021140204
000000017,000000017,C-100,N-101,0,04/02/2003,12/31/2001,,04/02/2003,,,,,,20031021140204
000000018,000000018,C-100,N-101,0,04/02/2003,12/31/2002,,04/02/2003,,,,,,20031021140204
000000019,000000019,C-100,N-106,0,04/02/2003,12/22/2002,,04/02/2003,,,,,,20031021140204
000000020,000000020,C-100,N-101,0,04/02/2003,03/31/2003,,04/02/2003,,,,,,20031021140204
000000021,000000021,C-800,N-120,0,04/02/2003,06/30/2002,,04/02/2003,,,,,,20031021140204
000000022,000000022,C-800,I-306,0,04/02/2003,03/31/2002,,,,,,04/02/2003,,20031021140204
000000023,000000023,C-100,N-101,0,04/02/2003,12/31/2002,,04/02/2003,,,,,,20031021140204
000000024,000000024,C-100,N-101,0,04/02/2003,03/31/2002,,04/02/2003,,,,,,20031021140204

REPORT VALIDATION

5/7/07

MODULE 1

UI Tax Validation Handbook

FIGURE 1.3

1-7

POPULATION 3
SUBPOPULATION 3.1 DISPLAY AFTER IMPORT INTO SUN-BASED DV SOFTWARE

REPORT VALIDATION

5/7/07

MODULE 1

UI Tax Validation Handbook

REPORT VALIDATION

1-8

POPULATION 3 REPORT VALIDATION SUMMARY

FIGURE 1.4

5/7/07

MODULE 1

REPORT VALIDATION

MODULE 1
TABLE 1.2

OVERVIEW OF MODULE 1 (FIGURE 1.5)
Figure
1.5
Task
No.

Who
Performs
Task

Description of Task

IS staff analyze the validation file specifications including:
1A. Sun-based DV Tutorial: the report validation record layouts
for each population. Also provided in Appendix F.
1B. Validation Handbook (Module 3): the state-specific data
element specifications that include the state’s specific screen
names, element names and value codes for each data
element.
1C. Duplicate Detection Criteria (Appendix E): the criteria that
the software uses to detect duplicates.
1D. Report Validation Specifications (Appendix A):
the
reporting and sampling specifications for each population.

IS staff extract detailed employer records from the state database(s). IS Staff
The extract process should include a routine to ensure that invalid
duplicates are excluded from the file, as specified in the duplicate
detection criteria in Appendix E.

IS staff import the validation files into the Sun-based DV software, IS Staff
which processes the files and assigns records to the subpopulations
specified in Appendix A. The software also calculates validation
values and transfers the validation values to the Report Validation
Summary/Reported Counts Screen.

The RV Summary compares the validation values to the reported Sun-based
values and displays the error rates.
DV
software

UI Tax Validation Handbook

1-9

IS Staff

5/7/07

REPORT VALIDATION

MODULE 1
F IGURE 1.5
R EPORT V ALIDATION

Web-Based DV
Software Tutorial
(Record Layouts)

3
ETA 581 reported
values
automatically
transferred to RV
summary

IS analyzes
program
specifications and
develops extract
and formatting
program

Validation Handbook
Module 3 State-specific
Data Element Specs.
1C

IS runs
extract programs

Validation Handbook
Appendix E
Duplicate Detection
Criteria

RV Summary
compares the
validation and
reported values

Detailed Record
Extract File

Appendix A

IS imports extract into
web-based DV software

UI Tax Validation Handbook

1-10

Validation values
automatically
transferred to
RV Summary

5/7/07

DATA ELEMENT VALIDATION

MODULE 2

MODULE 2−DATA ELEMENT VALIDATION

The most important goal of the validation process is to determine how
accurately employer contributions transactions and statuses have been reported
on the ETA 581. After the report validation files have been built and each
transaction has been assigned to a specific subpopulation, the key question is whether
the data in each record are correct. This process is called data element validation
(DEV). In DEV, each data element in the report validation file is closely examined in
a small sample of transactions. DEV for the ETA 581 consists of two separate
procedures:

Module 2.1−File Integrity Validation (FIV). The DV software selects a
sample of two (2) records per subpopulation which are then displayed on the FIV
worksheet. The validator reviews the sampled records using the state-specific
data values and instructions in Module 3, which point the validator to the
appropriate supporting documentation (such as employer history screens). The
validator uses this documentation to validate that the data elements on the
worksheet are accurate and that the transactions are assigned to the appropriate
subpopulations. This test ensures that the data in the reconstruction file
accurately reflect the correct employer records in the state’s database(s).
Module 2.2−Range Validation provides additional validity tests that
examine whether state-specific codes are in the correct range for the
subpopulation to which the record has been assigned.

UI Tax Validation Handbook

2-1

5/7/07

DATA ELEMENT VALIDATION

MODULE 2

MODULE 2.1—FILE INTEGRITY VALIDATION

A. PROCEDURES
Task 1:

Select FIV Samples

The sampling function of the UI Tax DV software selects two records from
each subpopulation. See the tax tutorial for detailed instructions on how to use
the Sun-based DV software. For each population, the software creates an FIV
Samples Worksheet listing all data elements for each sampled record (see
example in Figure 2.1). Appendix D provides a sample FIV worksheet for each
population.
FIV can be done using a very small sample of records because the process
that states use to build the extract files is highly automated. Automated processes
are repetitive. If, for example, a certain field in the employer history file is
extracted and placed in the fifth column of the reconstruction file for one record,
that same field will be used for the fifth column of every record in that file. Thus,
if we know that all data elements have been transferred correctly for the sampled
records, we can be reasonably sure that all similar records are constructed
correctly.
Task 2:

Conduct FIV

For each data element in the sampled records, the validator compares the data
value on the worksheet to source screens following instructions in Module 3.
Based on that comparison, the validator records whether or not the value matches
what is in the state database. The source data can be found by referring to query
screens from the state data system.
These screens display information on
transactions and the status of employer accounts.1
Figure 2.2 is a sample page from Module 3. For each step listed in Module 3,
File Integrity Validation Instructions are provided. These instructions help the
validator locate and compare specific data elements in the state database to the
1

Elements requiring data from multiple fields pose a greater risk of reconstruction error. For
example, the reactivation date for status determinations may not come directly from one field in a
state’s database, but instead from a combination of a transaction code and a transaction date field.
There may be a series of applicable transaction codes representing reactivations. In these
instances, the state or region may want to examine the elements in greater detail. As discussed in
Module 1, states should produce the necessary screens as soon as possible after the reconstruction
file is created.

UI Tax Validation Handbook

2-2

5/7/07

DATA ELEMENT VALIDATION

MODULE 2

corresponding data on the worksheet, and to determine the validity of the
information (pass or fail).
The instructions for each step or substep identify the supporting
documentation (screen and field names) that the validator will need to examine.
A set of logic tests, called validation rules, determines the accuracy of each
characteristic of a given transaction. A subsection, called function, explains the
purpose of each rule.
Definitions listed for each step in Module 3 give the federal definition of the
item being validated. This definition is followed by further information on the
data element−examples, includes (situations falling within the definition), and
excludes.
Definitional Issues identify known discrepancies between state and federal
definitions. This section provides a place for states to systematically document
validation issues, letting validators and auditors know when problems are
anticipated. Where state and federal definitions differ, be sure to follow the
federal rules as required by the reporting instructions.
Comments provide additional information identified by states that state staff
or federal auditors may need in order to handle unusual situations.
Task 3:

Produce FIV Results

Select ‘PASS’ on the worksheet next to each data element that successfully
passes a step. Select ‘FAIL’ if a data element does not pass the step. Each
column on the worksheet must be validated before the FIV is considered complete
for a sampled record. Based on the pass/fail entries, the worksheet will provide
an item-by item count of the number of data elements that failed. All sampled
records must be completely free of errors for a state to pass FIV.
Once the state validator has finished reviewing all of the sampled records for
a population, the results should be saved and submitted to the national office
following the instructions in the software tutorial.

UI Tax Validation Handbook

2-3

5/7/07

DATA ELEMENT VALIDATION

MODULE 2

B. EXAMPLES
1.

Example of FIV Samples Worksheet (Figure 2.1)

Sample Page from Module 3 (Figure 2.2)

File Integrity Validation Procedures (Table 2.1 and Figure 2.3)

FIGURE 2.1
EXAMPLE OF FIV SAMPLES WORKSHEET

UI Tax Validation Handbook

2-4

5/7/07

DATA ELEMENT VALIDATION

MODULE 2

FIGURE 2.2
SAMPLE PAGE FROM MODULE 3

UI Tax Validation Handbook

2-5

5/7/07

DATA ELEMENT VALIDATION

MODULE 2

TABLE 2.1
OVERVIEW OF MODULE 2.1 (FIGURE 2.3)
Table 2.1 and Figure 2.3 summarize the tasks in the File Integrity Validation (FIV)
process.
Figure
2.3
Task
No.

Who
Performs
Task

Description of Task

Open FIV Samples Worksheet, which lists all data elements for two Validator
records from each subpopulation. A single worksheet is generated
for each population.

Produce necessary query screens at the same time reconstruction file IS Staff
is created.
Validator

The validator turns to the designated step in Module 3. Each step will
have one or more rules listed. The purpose or “Function” of each rule is
provided. In addition, each step includes the definition from the ETA
581. “Definitional Problems” is used to document instances where state
regulations or practices conflict with the federal definitions. The
“Comments” field can be used by the validator to record notes or
document issues that may be helpful for future validations.

Validator

The validator locates the source ΑDocument≅ listed to check each rule.
The document is the source used to compare the data on the worksheet
with the data residing in the state database or state files. In some cases,
it will not be necessary to pull any additional documents when all of the
data elements have been included on the worksheet. In other instances,
it will be necessary for the validator to refer to screens and/or case files.

Validator

The validator determines if the data element being validated passes Validator
all of the validation rules using the required documents.

If any of the rules for the step fail validation, the validator selects IS Staff
‘FAIL’ on the worksheet for that step.

If the data element passes all of the rules, the validator selects Validator
‘PASS’ on the worksheet for that step.

UI Tax Validation Handbook

2-6

5/7/07

UI Tax Validation Handbook

Validator locates
validation Instructions in
Module 3
- Looks up first step
number on worksheet
(Step 01)

Section of FIV Worksheet

Example of Module 3 step

Definition:

Definitional Problems:

Comments:

DEV Instructions:
NOT APPLICABLE

1. Document:
Rule:
Function:

FIV Instructions:
Select PASS on the worksheet if the
conditions are met, otherwise select FAIL:

Step 01 Match
3

2-7

Obtain
necessary
screens/
documents

State-specific
documents/
screens

Software records
total errors and
types of errors on
the worksheet

5/7/07

Click the box to
select FAIL

FAIL

Click the box to
select PASS
7

Does
data element
pass
all rules?

1) Worksheet
2) Step in Module 3
3) Screens/Documents

Determine if data element
passes all validation rules
using:

FAIL

PASS

Method for validating each data element for each sampled record on worksheet
Assume that validator needs to validate using an employer history screen

FIGURE 2.3
FILE INTEGRITY VALIDATION PROCEDURES

DATA ELEMENT VALIDATION

MODULE 2

MODULE 2.2—RANGE VALIDATION

Range validation consists of a series of tests that determine whether data
element values fall within the correct range for the subpopulation to which the
employer record has been assigned.
The validation software assigns records to subpopulations, in part by using
the generic codes used by all states to build the validation files. For example, all
states use ‘C’ to mean contributory followed by a dash and the state-specific code
for contributory. Range validation must be conducted when states have multiple
state-specific codes that could be assigned to a single generic code. Range
validation is also necessary when the state uses the Employer Account Number
(EAN) to identify the employer type (contributory or reimbursing).
Table 2.2 (on page 2-11) shows a variety of codes that one state uses to
classify a status determination that an employer is either newly liable or a
successor to an existing employer. In building its population 3 validation file, this
state might have several acceptable state-specific codes to map to the generic
status determination type indicators of “N” (new) and “S” (successor). For
example, this state’s validation file might show new status determination type
indicator values of N-01, N-02, N-08, or N-09.
In range validation, the validation software sorts the records in the extract file
to facilitate the identification of state-specific-codes that are not acceptable
matches for the generic code. A data element passes range validation if no more
than 2% of the sorted transactions include an incorrect state-specific code. An
extract file must pass all applicable range validation tests and have no FIV
samples with errors before the report validation can be confirmed as passing.
The DV software provides a data entry screen on which the validator records,
for each sort, the number of records subjected to the range validation test and the
number of records that are “out of range.”

UI Tax Validation Handbook

2-8

5/7/07

DATA ELEMENT VALIDATION

MODULE 2

A. PROCEDURES
Task 1:

Identify Applicable Range Validation Tests

Examine the range validation criteria in Table 2.3 (on pages 2-12 and 2-13).
For each potential sort look at the column entitled “When to Do Range
Validation” to determine if the sort is applicable to the state. A sort is only
applicable when there are multiple state codes that map to a single generic
indicator, or when the state uses the Employer’s Account Number (EAN) to
identify employer type (contributory or reimbursing).
Task 2:

Conduct Range Validation

See the tax software tutorial for a detailed explanation of how to conduct
range validation.
To begin range validation, log onto the Sun-based DV software and select the
appropriate population from the Tax Selection Criteria menu.
Select View Data Element Sorts from the drop down list.
Depending on the type of sort, enter the supplementary codes in the View
Data Elements Sort table.
The DV software only queries records in the subpopulations applicable to the
selected sort. Except for the EAN sorts, all of the sorts in Table 2.3 involve
instances where a state may have multiple codes for employer status, employer
type, or types of transactions. The software presents a combined distribution or
cross-tabulation of contributory and reimbursing employers, or, for example, all
status determinations, by the state-specific codes. The software displays the
results of the sort and allows the validator to review the sorted records.
Task 3:

Produce Range Validation Results

After examining the sorted records, the validator enters the total number of
employers or records for the given sort and the number of errors on the Data
Element Sorts screen. The DV software calculates the error rate and transmits the
results to the national office.
States have passed range validation when they have established that no more
than 2% of the records in the tax extract files include incorrect state-specific
codes, or incorrect EANs representing employer type.

UI Tax Validation Handbook

2-9

5/7/07

DATA ELEMENT VALIDATION
Task 4:

MODULE 2

Develop Corrective Action Plan (CAP)

Validation is not an end in itself; it is a means toward correct reporting. If
validation identifies reporting errors, the state should correct the reporting errors
as soon as possible.
To document the corrective action for resolving reporting errors, and the
timetable for completion, the state must submit a Corrective Action Plan (CAP) to
its ETA Regional Office in accordance with the annual State Quality Service Plan
(SQSP). The CAP should contain the following information on every validated
report element that exceeds the validation error rate tolerance:
•

Report element(s) in error.

•

Magnitude of error found.

•

Status/Plan/Schedule for correcting. If reporting errors were corrected in
the course of the first validation, the report should simply note “corrected
during validation.” (Validation of the affected transactions should occur
immediately after these corrections have been made.)

Timing of CAP. The CAP should be submitted within one month of submitting
the validation results to ETA. CAPs are considered additions to the SQSP. If the
state is conducting the validation in segments, e.g., benefits first, then tax, and a
CAP is required based on a segment’s validation results, the CAP should be
prepared within a month of the completion of that segment.
Revalidation. Every element in error by more than the stated validation limit
must be revalidated the following year. A “clean” validation confirms the success
of the corrective action or, if the state has not completed corrective action,
identifies the current extent of the error.
Errors Discovered Outside the Validation Process. During the validation
process, errors in reporting may be identified that are outside the scope of the
validation program. Such errors should be included in the comments section of
state’s validation reports and included in the CAP if warranted.
A CAP is also required for any state that fails to conduct the validation for either
the benefits or tax programs. Full validation will be repeated at regular intervals
or after changes to the state=s system have been made.
B. EXAMPLES

UI Tax Validation Handbook

2-10

5/7/07

DATA ELEMENT VALIDATION

MODULE 2

Status Determination Reason Codes (Table 2.2)

Range Validation Criteria (Table 2.3)

TABLE 2.2
STATUS DETERMINATION REASON CODES
This table lists codes that a state used to indicate the reason employers were subject to the
provisions of UI law as either a ‘new’ employer or as a ‘successor.’

Code

Reason

Payroll

Employment 13th week

FUTA

Whole Successor allowed

Part Successor

Consolidation allowed

Revived with new number

Payroll domestic

Payroll agriculture

Employment agricultural

UI Tax Validation Handbook

2-11

5/7/07

S1.2

S1.3

S1.4

S1.5

S2.1

S2.2

S2.3

S2.4

2.9-2.18

2.1-2.8

2.9-2.18

2.1- 2.8

1.2

1.1

1.1 and 1.2

1.2

1.1

Subpopulations
Sorted

UI Tax Validation Handbook

S1.1

Sort

Population

2-12

When more than one employer type code is used to
indicate that the employer type is reimbursing.

When more than one employer type code is used to
indicate that the employer type is contributory.

When the employer’s account number indicates that
the employer type is reimbursing.

When the employer’s account number indicates that
the employer type is contributory.

When more than one employer type code is used to
indicate that the employer type is reimbursing.

When more than one employer type code is used to
indicate that the employer type is contributory.

When more than one employer status code is used to
indicate that the employer’s status is active.

When the employer’s account number indicates that
the employer type is reimbursing.

When the employer’s account number indicates that
the employer type is contributory.

Employer
Type Indicator

EAN

Employer
Type Indicator

Employer
Status
Indicator

EAN

Test Data
Element

RANGE VALIDATION CRITERIA

TABLE 2.3

When to Do Range Validation

DATA ELEMENT VALIDATION

All employer type codes must
represent reimbursing employers

All employer type codes must
represent contributory employers

All EANs must be in ranges
allocated to reimbursing
employers

All EANs must be in ranges
allocated to contributory
employers

All employer type codes must
represent reimbursing employers

All employer type codes must
represent contributory employers

All status codes must represent
active employers

All EANs must be in ranges
allocated to reimbursing
employers

All EANs must be in ranges
allocated to contributory
employers

Test Criteria

Step 2B

Step 2A

Step 2B

Step 2A

Step 2B

Step 2A

Step 3A

Step 2B

Step 2A

5/7/07

Module 3
References

MODULE 2

S3.2

S3.3

S3.4

S4.1

S4.2

S4.3

4.3, 4.4,
4.11, 4.12

4.2, 4.10

4.1, 4.9

3.8

3.7

3.4-3.6

3.1-3.3

Subpopulations
Sorted

UI Tax Validation Handbook

S3.1

Sort

Population

2-13

When the state uses more than one code to indicate
that the transaction type is declared uncollectible.

When the state uses more than one code to indicate
that the transaction type is liquidation.

When the state uses more than one code to indicate
that the transaction type is establishment.

When the state uses more than one code to indicate
that the status determination type is termination.

When the state uses more than one code to indicate
that the status determination type is inactivation.

When the state uses more than one code to indicate
that the status determination type is successor.

When the state uses more than one code to indicate
that the status determination type is new.

Transaction
Type Indicator

Status Determination Type

Test Data
Element

RANGE VALIDATION CRITERIA

TABLE 2.3

When to Do Range Validation

DATA ELEMENT VALIDATION

All transactions must be accounts
receivable declared uncollectible

All transactions must be
liquidations of accounts
receivable

All transactions must be
establishment of accounts
receivable

All status determination type
codes must represent
‘termination’ status determination
type

All status determination type
codes must represent
‘inactivation’ status determination
type

All status determination type
codes must represent ‘successor’
status determination type

All status determination type
codes must represent ‘new’ status
determination type

Test Criteria

Step 21C

Step 21B

Step 21A

Step 11D

Step 11C

Step 11B

Step 11A

5/7/07

Module 3
References

MODULE 2

Module 3
FEDERAL DEFINITIONS AND STATE-SPECIFIC
VALIDATION INSTRUCTIONS

The inclusion of state-specific information in this module is not to be deemed
to be a finding that such information is in compliance with Federal reporting
data definitions.

UI Tax Validation Handbook

3-i

5/7/07

DATA ELEMENT VALIDATION INSTRUCTIONS

MODULE 3

MODULE 3--DATA ELEMENT
VALIDATION INSTRUCTIONS

Table 3.1 outlines each step in the state-specific validation instructions and its
component substeps. Table 3.2 indicates the combination of validation steps required for
validation of each population. The worksheet guides the validator to the necessary steps
by the presence or absence of data in each column for a given transaction. Each column
header identifies the steps to use in validating the data in that column. Once the validator
learns the instructions and rules listed under each step and substep, it may not be
necessary to refer to them for each transaction or element being validated.
The validator begins the validation by looking at the first transaction (first row) on
the worksheet and then by looking at the first step listed in the column header at the top
of the worksheet. The validator then locates that step in the state-specific instructions in
Module 3.
If there are substeps, but the substep is not specified in the column heading, the first
page for the step number will direct the validator to the appropriate substep.
Note: Some steps in Module 3 indicate that they do not require manual validation or
they are no longer required. The step numbers, however, have been retained in Module 3
to document the states’ procedures for these steps.

The inclusion of state-specific information in this module is not to be deemed a
finding that such information is in compliance with federal reporting data definitions.

UI Tax Validation Handbook

3-ii

5/7/07

DATA ELEMENT VALIDATION INSTRUCTIONS

MODULE 3

TABLE 3.1
DATA ELEMENT VALIDATION STEPS AND SUBSTEPS
Step

Substep A

Substep B

Substep C

Substep D

Substep E

Active
Employers

Employer Report
Filing

Status
Determinations

Accounts
Receivable

Field Audits

Match

Employer Type

Contributory

Reimbursable

Employer Status

Active

Inactive/
Terminated

Liability Date

Initial

Reopen

Inactive/Terminated as of Date

Inactivation and Termination
Processing Dates

Combined

Inactivation

Wages

Quarterly Wages

Number of
Liable Quarters

Employer Report Filing

Timely

Secured

Resolved

Received Date

New

Successor

Inactivation

Transaction Date

Established Date

Receivable
Established

Receivable
Liquidated

Contributory

Reimbursable

Large

Not Large

Change

No Change

Termination

10. Final Assessment Date
11. Status Determination Type

Termination

12. Status Determination Time Lapse
13. Status Determination Date
14. End of Liable Quarter
15. Activation Processing Date
16. Reactivation Processing Date
17. Successorship Processing Date
18. Predecessor Account Number
19. Receivable Dates
20. Due Date
21. Type of Transaction

Declared
Uncollectible

22. Established Amount
23. Liquidated Amount
24. Amount Declared Uncollectible
25. Amount Removed
26. Balance at End of Quarter
27. Age of Receivable
28. Employer Size
29. Change Audit Type

UI Tax Validation Handbook

3-iii

5/7/07

DATA ELEMENT VALIDATION INSTRUCTIONS

MODULE 3

TABLE 3.1 (continued)
Step

Substep A

Substep B

Substep C

Substep D

Substep E

31. Total Wages

Pre-Audit

Post-Audit

Under Reported

Over Reported

Reconciled

32. Taxable Wages

Pre-Audit

Post-Audit

Under Reported

Over Reported

Reconciled

33. Contributions

Pre-Audit

Post-Audit

Under Reported

Over Reported

Reconciled

30. Audit Completion Date

TABLE 3.2
RELEVANT DATA ELEMENT VALIDATION STEPS, BY POPULATION

Relevant Data Element Validation Stepsa

Population

- Active Employers

1, 2, 3, 5, 7, 14, 15, and 16

- Report Filing

1, 2, 4, 5, 6, 8, 9, 10, and 14

- Status Determinations

1, 2, 6, 11, 12, 13, 14, 15, 16, 17, and 18

- Accounts Receivable

1, 2, 19, 20, 21, 22, 23, 24, 25, 26, and 27

- Field Audits

1, 28, 29, 30, 31, 32, and 33

The appropriate substeps for each population are specified on the population tables in Appendix A.

UI Tax Validation Handbook

3-iv

5/7/07

QUALITY SAMPLE VALIDATION

MODULE 4

MODULE 4−TPS QUALITY SAMPLE VALIDATION

Tax Performance System (TPS) validation reviews the sample selection
procedures used by TPS. It ensures that the samples drawn to assess status
determination and field audit quality are randomly selected from the correct
populations.
There are two basic approaches to selecting samples. The first is a
conventional interval sample: the programmer (or a utility program) divides the
size of the desired sample (say 30) into the size of the population (say 300) and
derives the sample interval (every 10th observation). The programmer or the
utility program then selects a random start point (in this instance) between 1 and
10 and selects every tenth case from that point. The second approach is to use a
sampling utility program that randomizes the file and selects the first 30
observations. This approach is somewhat more difficult to validate, but could
involve a review of the sample against the source file or review of the utility
program specifications.

A. PROCEDURES
Task 1:

Compare Universe Counts

IS staff should obtain the following materials: copies of the universe files for
Status Determinations and Field Audits. The universe listings should cover all
quarters for which the acceptance sample was drawn. For status determinations
there will be three TPS universes: (1) New, (2) Successor, and (3)
Inactive/Terminated.
Compare the total count of the three status determination universes and one
field audit universe for the quarter to the count reported on the ETA 581 for that
three-month period. This validates that the correct universe was used.
Task 2:

Review Sample Selection

Determine if an interval sample was drawn (and how it was drawn) or if the
file was randomized such that the first set of cases could be selected without
establishing intervals.
If an interval sample was drawn, check to see that the proper cases were
selected (that is, if the random start was 10 and the interval was every 40th case,

UI Tax Validation Handbook

4-1

5/7/07

QUALITY SAMPLE VALIDATION

MODULE 4

check to see that cases 50, 90, 130, and so forth were selected). The validator can
identify the sampled cases from the quality review documentation.
If the sample was drawn from a randomized file, print the file and ensure that
it was not ordered by date, employer, or some other nonrandom means. The
validator can compare the printout with the way the file was ordered prior to
randomization to ensure that the file was randomly reordered.
Task 3:

Record Findings on TPS Comments Screen

Upon completing the review the validator should record findings on the
Enter TPS comments screen in the DV software. Figure 4.1 provides an
example.
On the form the validator enters:
•

The validator and state,

•

The universe reviewed,

•

The time period from which the sample was drawn, either quarter or
year,

•

The type of sampling procedure used (skip interval or automated), and

•

The results of the review.

If the sampling method was not correct or was not implemented properly, the
validator should discuss the problems with the programmer. If the programmer
confirms that the process was incorrect, the validator should record the problems
on the TPS comments form. The Enter TPS Comments screen is found on the
FIV/DEV menu for population 3 (status determinations) and population 5 (field
audits).

UI Tax Validation Handbook

4-2

5/7/07

QUALITY SAMPLE VALIDATION

MODULE 4

B. EXAMPLES
FIGURE 4.1
SAMPLE TPS COMMENTS SCREEN

UI Tax Validation Handbook

4-3

5/7/07

WAGE ITEM VALIDATION

MODULE 5

MODULE 5−WAGE ITEM VALIDATION

Each quarter, employers submit reports of wage records to the State agency
as paper records or as computerized files stored on magnetic tapes, diskettes, CDROMs, or as files transmitted over the Internet. A wage record lists an
individual’s earnings in covered employment; the individual employee is
identified by social security number (SSN) and usually also by name. The agency
creates a record in its files--called a wage item--that identifies the individual, his
employer, and the individual’s earnings for the quarter. The number of wage
items is one of the workload items used to allocate UI administrative funding and
is reported on the ETA 581 report. Wage item validation verifies that wage item
transactions processed in the report quarter are accurately reported. This helps
ensure equitable funding when this item is used to determine state workload.
Because it would be impractical to reconstruct all wage items counted on a
given ETA 581 report, wage item validation does not involve building a
reconstruction file of wage items processed. It is also impossible to conduct a
traditional DEV because employers, not the agency, have the original wage
information. Instead, validators recount small samples of wage items already
processed by the state. This approach allows states to validate wage items at any
time after they have been processed. In this recount, validators make sure that (a)
every wage item in a small sample was counted and (b) the count does not
include:

•

Corrections (the system must be able to process corrections without
double counting the item); or

•

Incomplete wage records (for example, if the identifier or wage
amount is missing for the employee); or

•

Duplicate records.

UI Tax Validation Handbook

5-1

5/7/07

WAGE ITEM VALIDATION

MODULE 5

A. PROCEDURES
Task 1:

Identify Modes of Data Capture

Identify the specific modes of data capture used by the state to process wage
records and enter each mode on a row on the Wage Item Validation Worksheet in
the UI Tax Data Validation software.
Task 2:

Select Sample from Each Mode

Select at least one batch of wage items from each mode of data entry. If the
state uses fewer than five wage item processing modes, select more than one
batch for the most common methods of entry so that at least five batches in total
are reviewed.
Task 3:

Enter ETA 581 Count for each Batch

For each of the modes entered on the Wage Item Validation Worksheet, enter
the number of wage items included in the ETA 581 count for the particular batch
being examined in the 581 Count for Batch column. This information must be
obtained from the system used to compile the wage item count for the ETA 581.
If more than one batch has been selected for a given mode, report each batch for
the mode on individual lines.
Task 4:

Recount Wage Items

The validator manually recounts the number of wage items in each of the
batches, for each mode, using the Federal definition for a countable wage item.
Ensure that there are no duplicate entries — that each wage record is counted
only once.
The validator must count only wage items that are complete. This means
each countable entry must include each of the following elements:

- Employee Identifier (Name or SSN)
- Employer Identifier (Name or EAN)
- Wage dollar amount

UI Tax Validation Handbook

5-2

5/7/07

WAGE ITEM VALIDATION

MODULE 5

Count as complete only those records containing a dollar amount and
elements that positively identify the worker either by name or SSN and the
employer by name or account number.
Corrected wage items are counted only if they were not previously included.
Task 5:

Enter Record on Wage Item Validation Worksheet

Enter the total number of valid wage items in the Recount for Batch column
on the Wage Item Validation Worksheet. If any duplicates or errors have been
identified, the validator researches the errors and indicates the nature of these
errors in the appropriate columns on the worksheet.
Task 6:

Submit and Save Wage Item Validation Results

The UI DV software calculates the difference between the validation and
reported counts for the validated sample of wage items. Wage Item Validation
passes if no batch contains more than 2% errors. If it passes, this part of
validation does not need to be repeated for three years; if it fails, it must be
repeated the following year.
Submit Wage Item Validation results by clicking the “Submit to National
Office” button at the bottom of the Worksheet. Results for a validation year must
be submitted by May 10. Because these results are only saved in the software
until the next validation or a reload of the software, it is recommended that the
validator save the results by taking a screen print.
Task 7:

Follow Up on Wage Item Validation Errors

If the wage item validation identifies errors, the validator should discuss the
errors with the programmer or individual responsible for wage item processing,
and the state should determine whether the error affects other batches of wage
items as well.

UI Tax Validation Handbook

5-3

5/7/07

WAGE ITEM VALIDATION

MODULE 5

B. EXAMPLES
1.

Wage Item Validation Worksheet (Figure 5.1)

Figure 5.1 shows an example of a Wage Item Validation Worksheet, listing a
number of possible modes of wage item processing in the first column. In this
particular state, the validator has chosen one batch from each mode and all of the
batches were processed on the same day. The column labeled “581 Count for
Batch” has been filled in with the number of wage items processed in this batch
and included in the ETA 581 count of wage items processed during the quarter.
Once the validator has recounted the wage items for each batch, the recount is
entered in the column labeled “Recount for Batch.” The difference between the
581 count and the recount is automatically calculated, as is the percent of errors.
The percent of errors is the Difference divided by the Recount. The validator
should enter the number of errors in each of the categories to aid in researching
problems. The total errors may be greater than the difference if the original 581
count did not include some legitimate, countable wage items.
In this example, the worksheet shows no discrepancies on the scanning and
computer disk recounts, and the electronic transfer and magnetic tape modes have
minor discrepancies; these four are therefore considered to be valid. The recount
of the data entry batch, however, indicates 563 errors, including 67 missing ID
numbers, 43 entries with missing amounts, and 123 double counts; therefore this
mode fails. This requires further research to establish the reason for the
miscounts and to correct any other errors caused by the use of this mode of
processing. The other modes on the worksheet showing differences may also be
researched.

UI Tax Validation Handbook

5-4

5/7/07

WAGE ITEM VALIDATION

MODULE 5
FIGURE 5.1

WAGE ITEM VALIDATION WORKSHEET

UI Tax Validation Handbook

5-5

5/7/07

APPENDIX A
REPORT VALIDATION FILE SPECIFICATIONS

APPENDIX A

Part I
Terminology and Timelines

UI Tax Validation Handbook

A.2

5/7/07

APPENDIX A
REPORT VALIDATION FILE SPECIFICATIONS

As described in Module 1 of the handbook, the first step in the data validation
process is to create report validation (RV) files (also referred to as extract or
reconstruction files). These files list records of all transactions and account statuses
that should be reported on the ETA 581 report. Each record is assigned to a single
population and to only one subpopulation within the population.
Appendix A specifies how the populations are divided into subpopulations.
Each row of a population table is the specification for a single, mutually exclusive
subpopulation. At the end of each table is a written description of each subpopulation
which will help readers orient themselves to the information in the table.
Each column header includes a step number that refers to the state-specific
portion of the handbook in Module 3. Validators and programmers should refer to
the indicated step number for detailed instructions on how to validate the data in that
column, as well as for the definition of the data element. Each population table
includes a column and/or row entitled “Reported in ETA 581 Item #s,” which
indicates the item number on the ETA 581 that the count or dollar amount in the
column or row is compared with on the RV summary report.
States should reconstruct each population as specified for a recent ETA 581
report quarter (RQ). In addition, states that administer unemployment insurance
together with other taxes should capture tax type, to distinguish between the taxes
being validated on the ETA 581 and others which are not countable on the report.1

Some states may have other unique types of data elements which should be captured in the
reconstruction file to facilitate validation. For example, some states may have an indicator for seasonal
employers which would be helpful in validating subpopulations 2.7 and 2.15 in population 2.

UI Tax Validation Handbook

A.3

5/7/07

APPENDIX A:
REPORT VALIDATION FILE SPECIFICATIONS
A. REPORT QUARTER TERMINOLOGY
The specifications in this appendix use a shorthand terminology to refer to report
quarters. Figure A.1 is a time line illustrating how terms and symbols are used.
•

The Report Quarter (RQ) is the time period shown on the ETA 581 in
the block labeled “A. Report for quarter ended.” This means that the
ETA 581 report is showing transactions that occurred during this quarter
or the status of accounts at the end of this quarter. For example, the ETA
581 report includes items such as the number of active employers at the
end of the RQ and the number of timely employer reports received during
the RQ. The RQ ends at point A in Figure A.1. (Point A is also the time
when the state runs programs to download data for both the ETA 581
counts and the data validation reconstruction files.) The ETA report that
relates to the RQ is due at the hashmark labeled “ETA 581 Due” in
Figure A.1.

•

Contribution and wage reports received from employers during the RQ
reflect employer activity (payment of wages) that occurred during the
quarter before the RQ (RQ-1). Because this prior quarter is the subject
of employer reports received during the RQ, RQ-1 is sometimes referred
to as the Employer Report Quarter (ERQ). When specifications need
to refer to earlier quarters, they will extend the basic convention. The
quarter prior to RQ-1 is RQ-2, the quarter prior to that is RQ-3, and so
on.

•

The specifications refer to the quarter after the RQ using the term RQ+1.
This term is used most often for population 2, report filing, where states
have through RQ+1 to resolve reports due in RQ.

UI Tax Validation Handbook

A.4

5/7/07

APPENDIX A:
REPORT VALIDATION FILE SPECIFICATIONS

FIGURE A.1
QUARTERLY TIMELINE

2005
Jan

1
Feb

2
Mar Apr May Jun

RQ-1 (ERQ)
• contribution reports
covering employer
activity in this quarter
can be resolved by
RQ+1

Employer
Reports Due
(for RQ-2)

RQ: Report Quarter
States:
• register employers
• determine their
liability status
• receive contribution
reports on employer
activity in RQ-1
• pursue delinquent
reports
• establish, liquidate,
and write off
receivables
• complete field audits

Jul

Sep

Oct

4
Nov

Dec

RQ+1
States:
• receive contribution
reports on employer
activity in RQ
• resolve contribution
reports due in RQ on
employer activities in
RQ-1

ETA 581
Due
(for RQ+1)

ETA 581
Due
(for RQ)

Employer
Reports Due
(for RQ-1)

A
A

3
Aug

IS Staff: Produce Report Counts
Prepare Validation Extract Files (except for Population 2)
Prepare Screen Prints
Validation extract file prepared for Population 2, as soon as all reports received
during RQ+1 are posted

UI Tax Validation Handbook

A.5

5/7/07

APPENDIX A:
REPORT VALIDATION FILE SPECIFICATIONS
Following is a summary list of abbreviations and terminology used in the file
specifications.
RQ

ETA 581 report quarter

ERQ

Employer Report Quarter (quarter covered by employer=s
contribution report)

FDRQ

First day of the report quarter

LDRQ

Last day of the report quarter

(RQ+1)

Quarter after the report quarter

(RQ-1)

Quarter before the report quarter

(RQ+n)

nth quarter after the report quarter

(RQ–n)

nth quarter prior to the report quarter

Due date for employer contribution reports

Active

Contributory Employer

Reimbursing Employer

OBS

Observation number

After the date or quarter specified, e.g., “> RQ” means “after the
report quarter.”

Prior to the date or quarter specified, e.g., “< RQ” means “prior to the
report quarter.”

≥

During or after the date or quarter specified, e.g. “≥ RQ” means
“during or after the report quarter.”

≤

During or prior to the date or quarter specified, e.g. “≤ RQ” means
“during or prior to the report quarter.”

UI Tax Validation Handbook

A.6

5/7/07

APPENDIX A:
REPORT VALIDATION FILE SPECIFICATIONS
B. TIMELINES
Each population on the ETA 581, and therefore each population file for
validation, represents a particular timeline of UI tax operations activity. Populations
1, 3, and 5 are fairly straightforward ― these populations are primarily focused on
activities during or statuses at the end of the RQ. Populations 2 and 4 are more
complex and require the validator to look back as far as eight quarters prior to the
RQ, and forward as far as two quarters after the RQ. In Figure A.2 below, the RQ
being validated is the second quarter of 2005, which means RQ-8 is the second
quarter of 2003 and RQ+2 is the fourth quarter of 2005. Once the state has selected
the quarters to be validated for populations 2 and 4, the validator should prepare a
full timeline based on Figure A.2, identifying the eight quarters prior and two
quarters after the selected RQ.
FIGURE A.2
SAMPLE TIMELINE FOR REPORT QUARTER 200502 (SECOND QUARTER OF 2005)
2003
Q2

2003
Q3

2003
Q4

2004
Q1

2004
Q2

2004
Q3

2004
Q4

2005
Q1

2005
Q2

2005
Q3

2005
Q4

RQ-8

RQ-7

RQ-6

RQ-5

RQ-4

RQ-3

RQ-2

RQ-1
(ERQ)

RQ+1

RQ+2

C. OVERVIEW OF POPULATIONS
The ETA 581 for the second report quarter of 2005, which is due in August of
2005, contains the following information and is validated as follows:
POPULATION 1
o

The ETA 581 includes active employer information as of June 30, 2005.
!

This report information is validated by building a Population 1 extract
file for the second quarter of 2005. Population 1 should include a
record for each employer who was active on the last day of the RQ.

UI Tax Validation Handbook

A.7

5/7/07

APPENDIX A:
REPORT VALIDATION FILE SPECIFICATIONS
!

The DVWS filters pending employers out of the active employers
count, in accordance with the Department of Labor’s Change 12 to the
ET 401 handbook. Specifically, the filter will not include employers in
the count if their activation or reactivation processing date is prior to
their met threshold date, when the met threshold date is after
12/31/2002.

Figure A.1, Point A shows when the Population 1 validation file should
be constructed.

POPULATION 2
o

The ETA 581 includes employer reports received on time and secured
during the second quarter of 2005 that relate to employer activity during the
first quarter of 2005, and resolved reports that were due during the first
quarter of 2005 and relate to employer activity in the fourth quarter of 2004.
!

Population 2 should include all employers owing contributions or
required reports for the same ERQ, due during the RQ, which were
received on time or secured during the RQ or reported as resolved
during RQ+1.

Timely, secured, and resolved counts for the same ERQ (e.g., 200501)
are validated at the same time by building a Population 2 file that is
extracted at the end of the third quarter of 2005. This Population 2
extract file validates timely and secured counts that are reported on the
ETA 581 report for the second report quarter of 2005 and resolved
counts that are reported on the ETA 581 report for the third quarter of
2005.

Note that timely, secured, and resolved are defined as discrete filing
statuses for validation purposes, whereas on the ETA 581 secured
includes timely and resolved includes both.
The received date of the contributions report is used to assign records
to subpopulations 2.1, 2.2, 2.3, 2.9, 2.10, and 2.11. Because the
received date of a given contributions report does not change once it is
entered into the state system, the validation records for timely and
secured reports do not need to be extracted at the end of the RQ.
Instead, the entire population extract can be run at the end of RQ+1

UI Tax Validation Handbook

A.8

5/7/07

APPENDIX A:
REPORT VALIDATION FILE SPECIFICATIONS
when resolved report records are available. The validation counts in
subpopulations 2.1, 2.2, 2.9, and 2.10 are compared with ETA 581
counts for the RQ; all subpopulation validation counts are compared
with reported counts for RQ+1 (see 581 Item # references in the
population tables on pages A.16 and A.17).
!

In preparing the Population 2 extract file, states will need to account
for annual filers. According to DOL, annual filers must be counted as
timely for the quarters in which their reports are not due, and as timely,
secured or resolved, as appropriate for the quarters in which their
reports are due. States will need to enter a default employer report
quarter and default received date for annual employers for the quarterly
reports that are not due, and either a received date, final assessment
date, or appropriate resolved date for annual employers for the
quarterly reports that are due. This should ensure that the quarterly
reports that are not due are counted as timely, and that the quarterly
reports that are due are counted appropriately as timely, secured or
resolved.

Figure A.1, Point B, shows when the Population 2 validation file
should be constructed.

POPULATION 3
o

The ETA 581 includes status determination activities that occurred during
the second quarter of 2005.
!

This report information is validated by building a Population 3 extract
file for the second quarter of 2005. Population 3 includes a record for
each status determination made by the state during the RQ; multiple
determinations for the same employer are countable and should be
included in the file as separate records.

States that overwrite status determinations on their master tax file may
use the TPS universe for reconstruction. Programmers and validators
should note that time lapse categories are discrete subpopulations,
whereas the ETA 581 reports time lapse cumulatively.

The pending employer filter also applies to subpopulations 3.1 to 3.3,
which are for new status determinations.

UI Tax Validation Handbook

A.9

5/7/07

APPENDIX A:
REPORT VALIDATION FILE SPECIFICATIONS

Figure A.1, Point A, shows when the Population 3 validation file
should be constructed.

POPULATION 4
o

The ETA 581 includes receivables activity that occurred during the second
quarter of 2005 related to wage reports and contributions that are past due
from the ERQ of the first quarter of 2005 and previous quarters. This
includes receivables established, liquidated, declared uncollectible and
removed during the second quarter of 2005.
!

This report information is validated by building a Population 4 extract
file for the second quarter of 2005. Population 4 includes all
accounting transactions made during the RQ that establish or modify a
receivable on an employer account.

Receivables records need both the ERQ and the established date to be
properly assigned to Subpopulations 4.4, 4.5, 4.6 and 4.8, and both the
due date and the established date to be properly assigned to
Subpopulations 4.12, 4.13, 4.14 and 4.16.

Occasionally, receivable balances due to be removed in the RQ are
declared uncollectible in the RQ. These should be reported as
uncollectible on the ETA 581 and classified as uncollectible when the
extract file is built. However, the validation software will consider
them removed records on the basis of their established dates and ERQs
and reject them as errors. Because such occurrences are rare, the effect
should be within the two percent error tolerance.

For Population 4, Subpopulations 4.7, 4.8, 4.15 and 4.16, programmers
should generate separate balance records for a single employer, for
each ERQ where there is a balance at the end of the RQ.

Figure A.1, Point A, shows when the Population 4 validation file
should be constructed.

POPULATION 5

UI Tax Validation Handbook

A.10

5/7/07

APPENDIX A:
REPORT VALIDATION FILE SPECIFICATIONS
o

The ETA 581 includes audit activity (for example, audit completions)
reported during the second quarter of 2005.
!

This report information is validated by building a Population 5 extract
file for the second quarter of 2005. Population 5 includes all field
audits completed during the RQ.

Data elements specified on the file specification may not be captured
on the state’s system when they are not reported on the 581. They are
however included in the auditor’s paper files during the validation for
the cases sampled for FIV. When states cannot capture such
information automatically, the column can be completed from the
auditor’s paper files during the validation for the selected cases.

Figure A.1, Point A, shows when the Population 5 validation file
should be constructed.

UI Tax Validation Handbook

A.11

5/7/07

APPENDIX A

Part II
Population Table Specifications

UI Tax Validation Handbook

A.12

5/7/07

APPENDIX A:
POPULATION TABLE SPECIFICATIONS
EXPLANATION OF UI TAX DATA FORMATS
There are 6 types of data formats referred to in Appendix A and Appendix F.
1.

Required. These fields cannot be blank. They may be mandatory codes, dates
or dollar values. Required cells in Appendix A tables indicate the required code,
date, or dollar value parameters, or display the word “Required.”
Required text fields have code values that must be entered, such as A, C, R, etc.
All of the allowable generic values for each field are listed in the Data
Type/Format column on the record layout. The generic values must be followed
by a dash and the corresponding state-specific value.

Conditionally required. Data are included in these fields if the data are present
in the state’s system. Applies to date and wages fields.

Optional. These fields are gray in Appendix A and the word “Optional” is
displayed. The software does not look at these fields at all. Any values can be
entered or they can be left blank.

Must be blank. These are text or date fields where the presence of data
indicates an error. Therefore, they must be left blank (such as population 4
transaction date for balance subpopulations 4.7, 4.8, 4.15, and 4.16).

Must be blank or 0. These are numeric fields where the presence of data other
than 0 indicates an error. In tax these are primarily wages fields in populations
4 and 5.

System generated. These fields are generated by the DV software and data
should not be placed in these fields in the extract files. These fields are
primarily time lapse and age fields.

Some values are abbreviated in the record layouts (Appendix F) but are shown in the
report validation specifications (Appendix A) in their entirety for informational
purposes.

UI Tax Validation Handbook

A.13

5/7/07

APPENDIX A:
POPULATION TABLE SPECIFICATIONS
Notes:
For most steps referenced in Appendix A column headers, Rule 1 is the indicator in
the state system. However, if a state does not maintain the indicator specified in
Rule 1, then the state programmer must review the other rules in that step in order to
develop the required validation logic.
The extract file type is ASCII, comma delimited. Data must be in the order listed in the
record layouts.

UI Tax Validation Handbook

A.14

5/7/07

Subpopulation

1.1

1.2

Required

EAN

Employer
Status
Indicator

2
(Step 3A)

Employer
Type

3
(Step 2A)
(Step 2B)

≤ RQ

Liability Date
(Met
Threshold)

4
(Step 14)

met threshold,
or blank

≥ liability date

met threshold,
or blank

> RQ, or
< liability date

met threshold,
or blank

met threshold

≥ liability date

met threshold
and ≤ RQ

≥ liability date

> RQ, or
< liability date

≥ liability date
met threshold
and ≤ RQ, or
blank

Activation
Processing
Date

7
(Step 15)

Inactive/
Terminated
“as of” Date

6
(Step 5)

Reactivation
Processing
Date

5
(Step 16)

Number of
Liable
Quarters
If = 0, then
activation
processing
date, or
reactivation
processing
date, if
present,
must be in
RQ
If = 0, then
activation
processing
date, or
reactivation
processing
date, if
present,
must be in
RQ

8
(Step 7B)

(If Col. 8 = 8)
> $0

Sum of Wages
(Last 8 Q’s)

9
(Step 7A)

A.15

Active reimbursable employers liable by the end of the report quarter.

1.2

UI Tax Validation Handbook

Active contributory employers liable by the end of the report quarter.

1.1

Subpopulation descriptions:

5/7/07

2) Column 9 sums the reported wages for the last 8 quarters. The record layout for the software specifies that the states list all 8 quarters. The software
detects non-zero values for wages across quarters.

1) Column 8 reports the consecutive number of liable quarters ending with the RQ. If the number is greater than 8, simply list 8.

Notes

Reported in
ETA 581
Item #’s

1
(Step 1A)

Population 1: Report Validation File Specifications, Active Employers

APPENDIX A: POPULATION TABLE SPECIFICATIONS

Required

7, (8 in
RQ + 1)

8 in RQ + 1

9, 10, (11 in
RQ + 1)

10, (11 in
RQ + 1)

2.2

2.3

2.4

2.5

2.6

2.7

2.8

2.9

2.10

UI Tax Validation Handbook

Required

6, 7, (8 in
RQ + 1)

EAN

2.1

Subpopulation

1
(Step 1B)

RQ - 1

Employer Report
Quarter
(ERQ)

2
(Step 1B)

Employer
Type

3
(Step 2A)
(Step 2B)

Required if Date
Exists
Required if Date
Exists

> DD but
within RQ

Required if Date
Exists

≤ DD

A.16

Must be blank

Required if Date
Exists

RQ or RQ + 1

Required if Date
Exists
Must be blank

Required if Date
Exists

Final Assessment
Date

5
(Step 10)

RQ + 1

> DD but
within RQ

≤ DD

Received Date

4
(Step 9)

Required
if Date
Exists
= Col. 8
date
Required
if Date
Exists
Required
if Date
Exists

Required
if Date
Exists

Liability
Date
(Met
Threshold)

Liability
Date
(Initial or
Reopen)
Required
if Date
Exists
Required
if Date
Exists
Required
if Date
Exists
Required
if Date
Exists
Required
if Date
Exists

Required if
Date Exists

≥ RQ

Required if
Date Exists

7
(Step 14)

6
(Step 4A)
(Step 4B)

Population 2: Report Validation File Specifications, Report Filing

POPULATION TABLE SPECIFICATIONS

Reported in
ETA 581
Item #’s

APPENDIX A:

Required if
Date Exists

date

= Col. 6

Required if
Date Exists

date (met
threshold),
or blank

> RQ and
> liability

< RQ - 1

Required if
Date Exists

Inactive/
Terminated
“as of” Date

8
(Step 5)

Must be
blank

RQ - 1

Must be
blank

Suspended
“as of”
Quarter

9
(Step 5)

7/2/07

Required if
Date Exists

RQ or RQ + 1

Required if
Date Exists

RQ or RQ + 1

Required if
Date Exists

Inactivation/
Termination
Processing
Date

10
(Step 6A)
(Step 6B)
(Step 6C)

Required

11 in
RQ + 1

2.12

2.13

2.14

2.15

2.16

Required if Date
Exists

RQ or RQ + 1

Required if Date
Exists

Final Assessment
Date

5
(Step 10)

Required
if Date
Exists
= Col. 8
date

Required
if Date
Exists

Liability
Date
(Met
Threshold)

Liability
Date
(Initial or
Reopen)
Required
if Date
Exists
Required
if Date
Exists
Required
if Date
Exists

Required if
Date Exists

≥ RQ

Required if
Date Exists

7
(Step 14)

6
(Step 4A)
(Step 4B)

date

= Col. 6

Required if
Date Exists

date (met
threshold),
or blank

> RQ and
> liability

< RQ-1

Required if
Date Exists

Inactive/
Terminated
“as of” Date

8
(Step 5)

Must be
blank

RQ - 1

Must be
blank

Suspended
“as of”
Quarter

9
(Step 5)

RQ or RQ + 1

Required if
Date Exists

RQ or RQ + 1

Required if
Date Exists

Inactivation/
Termination
Processing
Date

10
(Step 6A)
(Step 6B)
(Step 6C)

UI Tax Validation Handbook

A.17

7/2/07

States should identify all contributory and reimbursing employers who were required to file a report covering the quarter prior to the ETA 581 report
quarter, on the last day of the quarter prior to the ETA 581 report quarter. That data file can then be used in the validation reconstruction, even
though not every report owed will be resolved. (If this approach is workable for states, it can also be done every quarter to program the ETA 581.)

Must be blank

Required if Date
Exists

RQ + 1

Received Date

4
(Step 9)

Employer
Type

3
(Step 2A)
(Step 2B)

A few states resolve reports for seasonal employers by suspending the report filing requirement in off seasons (subpopulations 2.7 and 2.15). Most
states will not have values for “suspended as of quarter.”

RQ - 1

Employer Report
Quarter
(ERQ)

2
(Step 1B)

Notes:

Required

11 in
RQ + 1

EAN

2.11

Subpopulation

1
(Step 1B)

Population 2: Report Validation File Specifications, Report Filing

POPULATION TABLE SPECIFICATIONS

Reported in
ETA 581
Item #’s

APPENDIX A:

If an employer has more than one resolved date under columns 4, 5, 8, or 9, the software assigns the record to the first subpopulation for which it
meets the criteria.

Contributory employers owing contributions reports for activities in RQ - 1, who received a legally due and collectible enforcement (final
assessment) by the end of RQ + 1 (resolved, neither secured nor timely).

Contributory employers owing contributions reports for activities in RQ - 1, who were made inactive during RQ, or during RQ + 1 (resolved, neither
secured nor timely), and whose inactivation was effective prior to the ERQ.

Contributory employers owing contributions reports for activities in the RQ - 1, whose liability date (met threshold) was changed from prior to the
RQ, to during or after RQ (resolved, neither secured nor timely).

Contributory employers owing contributions reports for activities in RQ - 1, who were suspended from filing contribution reports due in RQ by virtue
of being seasonal employers, an administrative decision not to pursue report filing, or for other reasons (resolved, neither secured nor timely).

Contributory employers owing contributions reports for activities in RQ - 1, whose accounts were withdrawn by making the liability date and the
inactive/terminated “as of” date equal (resolved, neither secured nor timely). This includes canceled, withdrawn, closed, dropped, etc. accounts.

Reimbursable employers owing required reports for activities in RQ - 1, who filed required reports timely by the due date.

2.4

2.5

2.6

2.7

2.8

2.9

7/2/07

Contributory employers owing contributions reports for activities in RQ - 1, who filed contribution reports during RQ + 1 (resolved, neither secured
nor timely).

2.3

A.18

Contributory employers owing contributions reports for activities in RQ - 1, who filed untimely contribution reports by the end of RQ (secured, but not
timely).

2.2

UI Tax Validation Handbook

Contributory employers owing contributions reports for activities in RQ - 1, who filed contribution reports timely by the due date.

2.1

The software assigns records to the first subpopulation for which it meets the subpopulation criteria. Each record is compared to the requirements for
subpopulation 1 and the software determines if the record meets the subpopulation 1 criteria. If it does, the record is assigned to subpopulation 1. If it
does not, the software then compares the record to the requirements for subpopulation 2 and determines if the record meets the subpopulation 2 criteria.
This process continues as necessary comparing each record to the requirements for each successive subpopulation.

Subpopulation descriptions:

Some states may use a delinquency flag instead of the preferred received date; this creates audit trail issues to be reviewed on a state-specific
basis.

Population 2: Report Validation File Specifications, Report Filing

POPULATION TABLE SPECIFICATIONS

APPENDIX A:

Population 2: Report Validation File Specifications, Report Filing

POPULATION TABLE SPECIFICATIONS

UI Tax Validation Handbook

A.19

7/2/07

2.16 Reimbursable employers owing required reports for activities in RQ - 1, whose accounts were withdrawn by making the liability date and the
inactive/terminated “as of” date equal (resolved, neither secured nor timely). This includes canceled, withdrawn, closed, dropped, etc. accounts.

2.15 Reimbursable employers owing required reports for activities in RQ - 1, who were suspended from filing required reports due in the RQ by virtue of
being seasonal employers, an administrative decision not to pursue report filing, or for other reasons (resolved, neither secured nor timely).

2.14 Reimbursable employers owing required reports for activities in RQ - 1, whose liability date (met threshold) was changed from prior to the RQ, to
during or after the RQ (resolved, neither secured nor timely).

2.13 Reimbursable employers owing required reports for activities in RQ - 1, who were made inactive during the RQ, or during RQ + 1 (resolved, neither
secured nor timely), and whose inactivation was effective prior to the ERQ.

2.12 Reimbursable employers owing required reports for activities in RQ - 1, who received a legally due and collectible enforcement (final assessment)
by the end of RQ + 1 (resolved, neither secured nor timely).

2.11 Reimbursable employers owing required reports for activities in RQ - 1, who filed required reports during RQ + 1 (resolved, neither secured nor
timely).

2.10 Reimbursable employers owing required reports for activities in RQ - 1, who filed untimely required reports by the end of the RQ (secured, but not
timely).

APPENDIX A:

14, 15, 16

14, 16

17, 18, 19

17, 19

Subpopulation

3.1

3.2

3.3

3.4

3.5

3.6

3.7

3.8

Required

EAN

1
(Step 1C)

C or R

Employer
Type

2
(Step 2A)
(Step 2B)

Terminations*

Inactivations*

Successor*

New*

Status
Determin.
Type
Indicator

3
(Step 11A)
(Step 11B)
(Step 11C)
(Step 11D)

Optional

Optional
RQ

≥ 91 but
≤ 180 days
≥ 181 days

≤ 90 days

≥ 91 but
≤ 180 days
≥ 181 days

Status
Determin.
Date

5
(Step 13)

≤ 90 days

Time Lapse

4
(Step 12)

Required

Required if
Date Exists
Required if
Date Exists

Required if
Date Exists

≤ successorship date
Required

Required if
Date Exists

RQ or
< Col. 9 date

Required if
Date Exists

≤ successorship date

RQ or
< Col. 9 date

Required if
Date Exists

Optional

≤ successorship date

RQ or
< Col. 9 date

Required if
Date Exists

Activation
Processing
Date

8
(Step 15)

End of
Liable
Quarter

7
(Step 14)

≤ successorship date

Liability
Date
(Met
Threshold)
≤ activation
processing
date
≤ activation
processing
date
≤ activation
processing
date

6
(Step 14)

Optional

≤ successorship date, or
blank
≤ successorship date, or
blank
≤ successorship date, or
blank

RQ or blank

Reactivation
Processing
Date

9
(Step 16)

Optional

Successorship
Processing
Date

10
(Step 17)

Population 3: Report Validation File Specifications, Status Determinations

POPULATION TABLE SPECIFICATIONS

Optional

Required

Optional

Predecessor
Account
Number

11
(Step 18)

Optional

RQa

Optional

Inactivation
Processing
Date

12
(Step 6A)
or
(Step 6B)

Optional

Termination
Processing
Date

13
(Step 6A)
or
(Step 6C)

UI Tax Validation Handbook

These values are abbreviated in the record layout.

A.20

Revised 6/11/07

There is the same issue as under Population #1, where the employer could be inactive based on 8 quarters of no wages (or fewer depending on the state’s threshold), but for some reason
the inactivation date/flag was not triggered. We may be able to cross-reference by EAN (by programming or on the printout) the employers identified as falling in this category from the
Population #1 specifications, since they are identical, as long as the same RQ is validated.

Reported in
ETA 581
Item #’s

APPENDIX A:

States that prefer to validate contributory and reimbursing employer status determinations separately for their own purposes may do so by
replicating the eight subpopulations (one set of eight subpopulations for each type of employer). States may prefer to validate the two types of
employers separately if they are processed in very different ways. However, such states must still submit a single RV summary to the National
Office with the combined results.

Population 3: Report Validation File Specifications, Status Determinations

POPULATION TABLE SPECIFICATIONS

Status determinations of successor employers made during the RQ, which were made within 90 days of the end of the quarter in which the
employer became liable.

Status determinations of successor employers made during the RQ, which were made between 91 and 180 days of the end of the quarter in which
the employer became liable.

Status determinations of successor employers made during the RQ, which were made 181 days or later from the end of the quarter in which the
employer became liable.

Inactivations of employers made during the RQ.

Terminations of employers made during the RQ.

3.4

3.5

3.6

3.7

3.8

Revised 6/11/07

Status determinations of new and reactivated employers made during the RQ, which were made 181 days or later from the end of the quarter in
which the employer became liable.

3.3

A.21

Status determinations of new and reactivated employers made during the RQ, which were made between 91 and 180 days of the end of the quarter
in which the employer became liable.

3.2

UI Tax Validation Handbook

Status determinations of new and reactivated employers made during the RQ, which were made within 90 days of the end of the quarter in which
the employer became liable. (Employers changing from contributory to reimbursing status and vice versa are included in subpopulations 3.1 - 3.3.)

3.1

Subpopulation Descriptions:

Notes:

APPENDIX A:

Required

4.1

4.2

4.3

4.4

4.5

4.6

4.7

4.8

Employer
Type

2
(Step 2A)
(Step 2B)

RQ - 2
Required
> RQ - 2

Must be
blank
Must be
blank

< RQ - 2

> RQ - 3

Required

Established
Q/Date

4
(Step 19B)

Optional

Transaction Date

3
(Step 19A)

≤ RQ - 8

> RQ - 8

≤ RQ - 8

RQ - 8

≤ RQ - 8

> RQ - 8

Required

Optional

Due Date

Employer
Report
Quarter
(ERQ)
Required

6
(Step 20)

5
(Step 1D)

A.22

Transaction
Type/Indicator

7
(Step 21A)
(Step 21B)
(Step 21C)

Must be
blank or 0
Must be
blank or 0

Must be
blank or 0

Optional

Must be
blank or 0
Must be
blank or 0

Must be
blank or 0

Optional

Must be
blank or 0

Must be
blank or 0
Must be
blank or 0

Must be
blank or 0

Optional

Must be
blank or 0

Must be
blank or 0
Must be
blank or 0

Must be
blank or 0

Must be
blank or 0
>0

5/7/07

Optional

Must be
blank or 0

Age of
Receivable

13
(Step 27A)
(Step 27B)

Must be
blank or 0

Balance at
End of RQ

12
(Step 26)

Must be
blank or 0

Amount
Removed

11
(Step 25)

10
(Step 24)

Amount
Uncollectible

9
(Step 23)

Amount
Liquidated

Amount
Established
in RQ

8
(Step 22)

Population 4: Report Validation File Specifications, Accounts Receivable

POPULATION TABLE SPECIFICATIONS

UI Tax Validation Handbook

Reported
in ETA
581
Item #’s

EAN

Subpopulation

1
(Step 1D)

APPENDIX A:

Required

4.9

4.10

4.11

4.12

4.13

4.14

4.15

4.16

Employer
Type

2
(Step 2A)
(Step 2B)

RQ - 2
Required
> RQ - 2

Must be
blank
Must be
blank

< RQ - 2

> RQ - 3

Required

Established
Q/Date

4
(Step 19B)

Optional

Transaction Date

3
(Step 19A)

Optional

≤ RQ - 7

> RQ - 7

≤ RQ - 7

RQ - 7

≤ RQ - 7

> RQ - 7

Required

Due Date

Employer
Report
Quarter
(ERQ)
Optional

6
(Step 20)

5
(Step 1D)

A.23

Must be
blank or 0

Must be
blank or 0
Must be
blank or 0

Must be
blank or 0
R

Must be
blank or 0

Optional

Must be
blank or 0
Must be
blank or 0

Must be
blank or 0

Optional

Must be
blank or 0

Must be
blank or 0
Must be
blank or 0

Must be
blank or 0

Optional

Must be
blank or 0

Must be
blank or 0
Must be
blank or 0

Must be
blank or 0

5/7/07

Optional

Optional
Must be
blank or 0

Must be
blank or 0

E
Must be
blank or 0

Age of
Receivable

13
(Step 27A)
(Step 27B)

Must be
blank or 0

Balance at
End of RQ

12
(Step 26)

Must be
blank or 0

Amount
Removed

11
(Step 25)

Must be
blank or 0

10
(Step 24)

9
(Step 23)

Amount
Uncollectible

Amount
Established
in RQ

8
(Step 22)

Amount
Liquidated

Transaction
Type/Indicator

7
(Step 21A)
(Step 21B)
(Step 21C)

Population 4: Report Validation File Specifications, Accounts Receivable

POPULATION TABLE SPECIFICATIONS

UI Tax Validation Handbook

Reported
in ETA
581 Item
#’s

EAN

Subpopulation

1
(Step 1D)

APPENDIX A:

5/7/07

States should not include negative values in individual transactions for report items. If a transaction made in one quarter is fully or partially adjusted
in a subsequent quarter, the adjustment should be reported using a positive entry to an appropriate adjustment category on the report. For
transactions made to an account that are fully or partially adjusted within the same quarter, states may report the net result. To ensure a proper audit
trail for validation purposes, adjustments should only be netted when they actually occur and are discovered within the same RQ. In these same
quarter situations, states may net adjustments but are not required to net if they prefer to maintain records of each transaction. The following table
specifies how to report and validate various types of receivables adjustments.

A.24

If states bill reimbursing employers on a monthly basis, then they may have up to three records for a receivable establishment in the RQ.

UI Tax Validation Handbook

There must be one record for each ERQ balance for an EAN to calculate aging.

Values in column 12 for all observations in subpopulations 4.15 - 4.16 should be totaled, for comparison to ETA Item #38.

Values in column 11 for all observations in subpopulations 4.13 - 4.14 should be totaled, for comparison to ETA Item #37.

Values in column 10 for all observations in subpopulations 4.11 - 4.12 should be totaled, for comparison to ETA Item #36.

Values in column 9 for all observations in subpopulation 4.10 should be totaled, for comparison to ETA Item #35.

Values in column 8 for all observations in subpopulation 4.9 should be totaled, for comparison to ETA Item #34.

Values in column 12 for all observations in subpopulations 4.7 - 4.8 should be totaled, for comparison to ETA Item #26.

Values in column 11 for all observations in subpopulations 4.5 - 4.6 should be totaled, for comparison to ETA Item #25.

Values in column 10 for all observations in subpopulations 4.3 - 4.4 should be totaled, for comparison to ETA Item #24.

Values in column 9 for all observations in subpopulation 4.2 should be totaled, for comparison to ETA Item #23.

Values in column 8 for all observations in subpopulation 4.1 should be totaled, for comparison to ETA Item #22.

Population 4: Report Validation File Specifications, Accounts Receivable

POPULATION TABLE SPECIFICATIONS

Notes:

APPENDIX A:

Receivable amounts declared uncollectible during the RQ for contributory employers where the receivable is at least eight quarters old but was
established within the RQ or the two preceding quarters. The establishment date parameter is used to confirm that these transactions have not
yet been removed.

Receivable amounts removed during the RQ for contributory employers where the receivable is eight quarters old and was established prior to
two quarters before the RQ.

Receivable amounts removed during the RQ for contributory employers where the receivable was at least eight quarters old and was established
two quarters prior to the RQ.

Receivable balances at the end of the RQ for contributory employers which were less than eight quarters old. (The receivable was not yet old
enough to be removed.)

4.4

4.5

4.6

4.7

5/7/07

Receivable amounts declared uncollectible during the RQ for contributory employers where the receivable is less than eight quarters old.

4.3

A.25

Receivable amounts liquidated during the RQ for contributory employers.

4.2

UI Tax Validation Handbook

Receivable amounts established as past due in the RQ for contributory employers.

4.1

Subpopulation descriptions:

+$500 Liquidated in RQ
+$500 Determined Receivable in next quarter’s report

Report net result ($0) in Liquidated

+$100 Liquidation in next quarter’s report

ETA 581
Report net result in Determined Receivable

Population 4: Report Validation File Specifications, Accounts Receivable

POPULATION TABLE SPECIFICATIONS

Adjustment
Error in new receivable identified and corrected within same
reporting period
$100 overstatement of new receivable identified and corrected in
following quarter
$500 check received, returned by bank for non-sufficient funds in
same quarter
$500 check received, returned by bank for non-sufficient funds in
following quarter

APPENDIX A:

Receivable amounts declared uncollectible during the RQ for reimbursable employers where the receivable is less than seven quarters old based
on the due date.

Receivable amounts declared uncollectible during the RQ for reimbursable employers where the receivable is at least seven quarters old based
on the due date but was established within the RQ or the two preceding quarters.

Receivable amounts removed during the RQ for reimbursable employers where the receivable is seven quarters old based on the due date and
was established prior to two quarters before the RQ.

Receivable amounts removed during the RQ for reimbursable employers where the receivable was at least seven quarters old based on the due
date and was established two quarters prior to the RQ.

Receivable balances at the end of the RQ for reimbursable employers which were less than seven quarters old based on the due date. (The
receivable was not yet old enough to be removed.)

Receivable balances at the end of the RQ for reimbursable employers which were at least seven quarters old based on the due date but which
were established within the RQ or the preceding quarter. (The receivable is old enough to be removed but is not removed because it has not yet
sat for 2 quarters in the ‘greater than 15 months’ aging category.)

4.11

4.12

4.13

4.14

4.15

4.16

5/7/07

Receivable amounts liquidated during the RQ for reimbursable employers.

4.10

A.26

Receivable amounts established as past due in the RQ for reimbursable employers.

4.9

UI Tax Validation Handbook

Receivable balances at the end of the RQ for contributory employers which were at least eight quarters old but which were established within the
RQ or the preceding quarter. (The receivable is old enough to be removed but is not removed because it has not yet sat for 2 quarters in the
‘greater than 15 months’ aging category.)

Population 4: Report Validation File Specifications, Accounts Receivable

POPULATION TABLE SPECIFICATIONS

4.8

APPENDIX A:

45, 47

46, 47

5.3

5.4

Required Required

UnderReported
(T3)
Must be
> 0 if
Cols. 9,
13, 14, 18,
19
all = 0
Must be
blank or 0
Must be
> 0 if
Cols. 9,
13, 14, 18,
19
all = 0
Must be
blank or 0
56

Optional

PreAudit
(X1)

PreAudit
(C1)

PostAudit
(C2)

Must be Must be
Must be
Must be Must be
Must be
Optional Optional
blank or 0 blank or 0 blank or 0
blank or 0 blank or 0 blank or 0

Optional

Must be Must be
Must be
Must be Must be
Must be
Optional Optional
blank or 0 blank or 0 blank or 0
blank or 0 blank or 0 blank or 0

Must be Must be
Must be Must be
> 0 if
> 0 if
> 0 if
> 0 if
Must be
Must be
Optional Cols. 8, 9, Cols. 8, 9,
Optional Optional Cols. 8, 9, Cols. 8, 9,
blank or 0
blank or 0
14, 18, 19 13, 18, 19
13, 14, 19 13, 14, 18
all = 0
all = 0
all = 0
all = 0

Optional

PostAudit
(X2)

Reconciliation
UnderOverAmount
Reported Reported (System
(C3)
(C4)
Generated)

17
18
19
20
(Step 33B) (Step 33C) (Step 33D) (Step 33E)

UI Tax Validation Handbook

A.27

5/7/07

Post audit figures for total wages, taxable wages and contributions reflect the net increase or decrease of under- and over-reporting identified
during the audit, even though the netted figures are not reportable on the ETA 581. Referring to the report validation file specification column
headers:

PostAudit
(T2)

16
(Step
33A)

PreAudit
(T1)

Reconciliation
UnderOverAmount
Reported Reported (System
(X3)
(X4)
Generated)

12
13
14
15
(Step 32B) (Step 32C) (Step 32D) (Step 32E)

Contributions

Some states may want to capture and store in the validation file the pre- and post-audit number of employees. Some states allocate a percentage
of their UI receipts to special funds or programs; if so, the employer’s discount rate and amount discounted should be included in the file.

Required Required

Audit
Change
CompAudit letion Date

Reconciliation
OverAmount
Reported (System
(T4)
Generated)
Must be
> 0 if
Cols. 8,
Must be
13, 14, 18, blank or 0
19
all = 0
Must be Must be
blank or 0 blank or 0
Must be
> 0 if
Cols. 8,
Must be
13, 14, 18, blank or 0
19
all = 0
Must be Must be
blank or 0 blank or 0

11
(Step
32A)

Taxable Wages

Notes:

Reported
in ETA 581
Item #’s

EAN

Employer
Audit ID #
Size

45, 46, 47 Required Required

5.2

5.1

Reported
Sub- in ETA 581
population Items #’s

Total Wages

Population 5: Report Validation File Specifications, Field Audits

POPULATION TABLE SPECIFICATIONS

1
2
3
4
5
6
7
8
9
10
(Step 1E) (Step 1E) (Step 28A) (Step 29A) (Step 30) (Step 31A) (Step 31B) (Step 31C) (Step 31D) (Step 31E)
(Step 28B) (Step 29B)

APPENDIX A:

A.28

Dollar values in column 19 for all observations in all four subpopulations should be totaled, for comparison to ETA Item #58.

Dollar values in column 18 for all observations in all four subpopulations should be totaled, for comparison to ETA Item #55.

Dollar values in column 14 for all observations in all four subpopulations should be totaled, for comparison to ETA Item #57.

Dollar values in column 13 for all observations in all four subpopulations should be totaled, for comparison to ETA Item #54.

Dollar values in column 9 for all observations in all four subpopulations should be totaled, for comparison to ETA Item #56.

Dollar values in column 8 for all observations in all four subpopulations should be totaled, for comparison to ETA Item #53.

Dollar values in column 7 for all observations in all four subpopulations should be totaled, for comparison to ETA Item #50.

Dollar values in column 6 for all observations in all four subpopulations should be totaled, for comparison to ETA Item #49.

The number of observations in all four subpopulations should be totaled, for comparison to ETA Item #47.

5/7/07

The validation software will reject records if the total wages reconciliation amount is not zero. However, the software does not reject records if the
taxable wages or contributions reconciliation amounts are not zero.

For example, if Employer A under reported total wages by $5,000 and also over reported total wages by $1,000, the Employer’s post-audit total
wages would increase by $4,000. So, if the validator nets the under and over reported wages the result is $4,000, and nets pre- and post-audit
wages the result is $4,000. These two results should always reconcile to zero. Referring again to the specification:
If TI = $10,000, T2 = $14,000, T3 = $5,000, T4 = $1,000, then ($10,000 - $14,000) - ($5,000 - $1,000) = 0.
Also, if TI = $10,000, T2 = $6,000, T3 = $1,000, T4 = $5,000, then ($10,000 - $6,000) - ($1,000 - $5,000) = 0.

UI Tax Validation Handbook

Population 5: Report Validation File Specifications, Field Audits

POPULATION TABLE SPECIFICATIONS

Subtract the positive net of (T3 - T4) from the positive net of (T1 - T2). The result in column 10 should be zero.
Subtract the positive net of (X3 - X4) from the positive net of (X1 - X2). The result in column 15 should be zero.
Subtract the positive net of (C3 - C4) from the positive net of (C1 - C2). The result in column 20 should be zero.

APPENDIX A:

Small employer audits completed during the RQ, which were change audits.

Small employer audits completed during the RQ, which were not change audits.

5.3

5.4

A.29

Large employer audits completed during the RQ, which were not change audits.

5.2

UI Tax Validation Handbook

Large employer audits completed during the RQ, which were change audits.

5.1

Population 5: Report Validation File Specifications, Field Audits

POPULATION TABLE SPECIFICATIONS

Subpopulation descriptions:

APPENDIX A:

5/7/07

APPENDIX B
INDEPENDENT COUNT

Appendix B
INDEPENDENT COUNT

APPENDIX B IS ONLY APPLICABLE TO POPULATIONS FOR WHICH
THE STATE HAS PRODUCED THE RV FILE FROM THE SAME
EXTRACT FILES USED TO PRODUCE THE ETA 581 REPORT.

A. PURPOSE
The validation procedures described in Modules 1 and Module 2 address the
validation of all UI contributions transactions that have been included in the ETA
581 report. However, it is also important to confirm that no transactions have been
improperly or systematically excluded from the Federal report. Although this
problem is a difficult one, it is important to ensure that funding, economic statistics,
and performance outcomes are not biased by the systematic elimination of particular
types of transactions.
This appendix is not applicable when states produce the RV file directly from the
employer contributions database, because the RV process itself constitutes an
independent count through the process of reconstruction. When the RV file is
produced from the same file used to produce the ETA 581 report, it is necessary to
conduct an independent count in order to identify any errors that may have occurred
in the ETA 581 report since these errors will be duplicated in the reconstruction file.
It is not possible to perform an independent count when the database does not
contain all of the reported transactions. In these circumstances, the statistical file is
the only source of data to reconstruct reported counts on the ETA 581 report. It is
unlikely that any state will need to perform an independent count for 581 validation
(it is more relevant to validating Federal benefits reports). This procedure is included
in this handbook to ensure that states are aware of the possible problems with using
statistical files for both reporting and validation when database files could be used.

UI Tax Validation Handbook

B.2

5/7/07

APPENDIX B: INDEPENDENT COUNT
B. PROCEDURES
IS staff create independent total counts of transactions from the main database for
comparison with counts generated on the extract files used to create the ETA 581. In
general, the independent count is created opposite to the way the RV file is created.
The RV file should be programmed from the bottom up, by selecting only the codes
and criteria indicated on the file specification in Appendix A. However, the
independent count should be programmed from the top down, by including all codes
relevant to a population and then subtracting observations that do not match the
population and subpopulation specifications. The specific type of independent count
(simple query, multiple queries, cross tabulation) must be determined by state
programming staff.
Table B.1 indicates when independent count validation is required. There are six
typical scenarios for how states produce the ETA 581 report and reconstruct counts
for validation. The ETA 581 Source column indicates for each scenario the source
files that states use to generate report counts. States may use different source files
for different types of transactions. The Data Validation Source column indicates for
each scenario the source files that states use to reconstruct lists of transactions for
validation.
The Independent Count Required column of Table B.1 indicates whether the state
should conduct independent count validation for populations that match the report
and validation scenario.
Table B.2 describes independent count criteria for each population.

UI Tax Validation Handbook

B.3

5/7/07

APPENDIX B: INDEPENDENT COUNT
TABLE B.1
ETA 581 REPORTING AND VALIDATION CONFIGURATIONS

Scenario

Transaction
s
Overwritten
on Database

ETA 581

Source

Timing

Independent
Count
Required

Program
Type

Source

Timing

Program
Type

Count

Database

Snapshot
(for
reporting
period)

Detail
Record
Extract
(DRE)

Database

Snapshot

Count

Stat file

Daily

DRE

Database

Snapshot

DRE

Database

Snapshot
(for
reporting
period)

DRE

Database

Snapshot

Yes

DRE

Stat file

Daily

DRE

Stat file

Daily

Yes

DRE

Stat file

Daily

DRE

Stat file

Daily

Yes

Count

Stat file

Daily

must
create a
daily
extract

UI Tax Validation Handbook

Data Validation

B.4

5/7/07

APPENDIX B: INDEPENDENT COUNT
TABLE B.2
INDEPENDENT COUNT CRITERIA BY POPULATION (USING QUERY CAPABILITY)
Population Description

Independent Count Criteria

Active Employers

States should not use statistical files to validate active employers because the
count should be taken from the database as a snapshot at the end of the month. If
states do not use this approach for reporting (if they instead derive the number
from changes in status over the quarter), they must use it for validation (they
cannot recreate the active employer population from the status changes).
Therefore, there is no situation that would require an independent count.

Report Filing

States generally use data files containing a record for each employer for both
reporting and reconstructing counts of employer report statuses. Therefore, there
is not likely to be a situation where statistical files are used for reporting or
validation. If a state uses a statistical file for validation, it should create a
frequency distribution of received dates for every employer with a received date
for the quarter being validated. This count can be used to validate that the
statistical file data matches the data base for all timely and secured reports and for
all reports which are resolved by receipt of a report. This will validate
subpopulations 2.1, 2.2, 2.3, 2.9, 2.10 and 2.11, which will be sufficient to
demonstrate that the statistical file is valid.

Status Determinations

States often use statistical files for reporting status determinations when their
system stores only the most recent status determination for each employer account
and thus overwrites previous status determinations. These statistical files are
often called RQC or TPS files because they were developed to provide a universe
of determinations from which to derive the RQC (now TPS) sample. These states
cannot perform an independent count from the database to validate the statistical
file because the database will not contain records for all of the status
determinations. Therefore, an independent count is not required for status
determinations, because it is not possible to create such a count in states that use
statistical files.

Accounts Receivable

All states must use a transaction history file or audit trail to correctly reconstruct
payments (amounts liquidated), because only such files show the date that each
payment was made. Transaction history files are also the source for receivable
amounts established and amounts declared uncollectible in some states. There is
only one source file for such transactions, so an independent count is not relevant.
All states must use Αemployer quarter files≅ to reconstruct balances for reporting
amounts removed and amounts outstanding at the end of the quarter. Some states
use such balances for reporting amounts declared uncollectible. These balances
are always captured as a Αsnapshot≅ at the end of the quarter from the database,
so an independent count is not relevant.

Field Audits

States do not maintain more than one file with field audit results, thus an
independent count is not relevant.

UI Tax Validation Handbook

B.5

5/7/07

APPENDIX C
REPORT VALIDATION SUMMARY REPORTS

UI Tax Validation Handbook

APPENDIX C

C.2

REPORT VALIDATION SUMMARY REPORT FOR POPULATION 1

5/7/07

REPORT VALIDATION SUMMARY REPORTS

UI Tax Validation Handbook

APPENDIX C

C.3

REPORT VALIDATION SUMMARY REPORT FOR POPULATION 2

5/7/07

REPORT VALIDATION SUMMARY REPORTS

UI Tax Validation Handbook

APPENDIX C

C.4

REPORT VALIDATION SUMMARY REPORT FOR POPULATION 3

5/7/07

REPORT VALIDATION SUMMARY REPORTS

UI Tax Validation Handbook

APPENDIX C

C.5

REPORT VALIDATION SUMMARY REPORT FOR POPULATION 4

5/7/07

REPORT VALIDATION SUMMARY REPORTS

UI Tax Validation Handbook

APPENDIX C

C.6

REPORT VALIDATION SUMMARY REPORT FOR POPULATION 5

5/7/07

REPORT VALIDATION SUMMARY REPORTS

APPENDIX D
FIV WORKSHEETS

UI Tax Validation Handbook

APPENDIX D

D.2

FIV WORKSHEET FOR POPULATION 1

5/7/07

FIV WORKSHEETS

UI Tax Validation Handbook

APPENDIX D

D.3

FIV WORKSHEET FOR POPULATION 2

5/7/07

FIV WORKSHEETS

UI Tax Validation Handbook

APPENDIX D

D.4

FIV WORKSHEET FOR POPULATION 3

5/7/07

FIV WORKSHEETS

UI Tax Validation Handbook

APPENDIX D

D.5

FIV WORKSHEET FOR POPULATION 4

5/7/07

FIV WORKSHEETS

UI Tax Validation Handbook

APPENDIX D

D.6

FIV WORKSHEET FOR POPULATION 5

5/7/07

FIV WORKSHEETS

APPENDIX E
DUPLICATE DETECTION CRITERIA

ETA 581 Reporting Rule

Count each employer once.
Multi-unit employers are counted
as one employer.

Each employer owes only one
report for each employer report
quarter (ERQ). This report is
counted a maximum of 3 times –
timely, secured, and resolved. If
an employer submits reports for
multiple ERQs at the same time,
only the report for the ERQ
immediately preceding the report
quarter (RQ) is countable as
timely (if applicable) and secured.
Only the report for the ERQ two
quarters prior to the RQ is
countable as resolved. Reports
from multi-unit employers are
counted as one report.

1. Active
Employers

2. Report Filing

UI Tax Validation Handbook

TABLE E.1

E.2

3. Employer Report
Quarter (ERQ)

If the EAN and ERQ are
identical in two or more records,
all of those records are rejected.

If the EAN is identical in two or
more records, all of those
records are rejected.

2. Employer Account
Number (EAN)

2. EAN

Data Validation
Duplicate Detection Rule
Applied to Extract File

Relevant Data
Elements from Extract
File (by Field
Number)

5/7/07

As long as EANs are only assigned at
the parent level, this should identify
units from the same multi-unit
employer.
As long as EANs are only assigned at
the parent level, this should identify
units from the same multi-unit
employer.

Comments

DUPLICATE DETECTION CRITERIA

UI TAX DUPLICATE DETECTION CRITERIA

Population

APPENDIX E

Each status determination
transaction should be counted
only once.

3. Status
Determinations

UI Tax Validation Handbook

Multiple determinations may be
legitimate, as long as they do not
reflect clerical errors.

Individual EANs may appear
more than once. For example,
there might be two transactions
listed for a single EAN if an
employer acquires two businesses
at different times during the
quarter, resulting in two
successorship determinations.

ETA 581 Reporting Rule

Population

TABLE E.1 (continued)

APPENDIX E

E.3

12. Predecessor
Account Number

6. Status Determination
Date

4. Status Determination
Type Indicator

Relevant Data
Elements from Extract
File (by Field
Number)
2. EAN

INACTIVATION or
TERMINATION (subpops 3.7
and 3.8), and the EAN and status
determination date are identical
in two or more records, all of
those records are rejected.

SUCCESSOR (subpops 3.4 –
3.6), and the EAN and status
determination date and
predecessor account number are
identical in two or more records,
all of those records are rejected.

NEW (subpops 3.1 – 3.3), and
the EAN and status
determination date are identical
in two or more records, all of
those records are rejected.

If the status determination type
indicator is:

Data Validation
Duplicate Detection Rule
Applied to Extract File

Comments

5/7/07

DUPLICATE DETECTION CRITERIA

No transaction should be listed
more than once.

4. Accounts
Receivable

UI Tax Validation Handbook

ETA 581 Reporting Rule

Population

TABLE E.1 (continued)

APPENDIX E

E.4

Relevant Data
Elements from Extract
File (by Field
Number)
2. EAN
4. Transaction Date
5. Established Date
6. Employer Report
Quarter (cont.)
7. Due Date (reimb.)
8. Transaction Type
9. Transaction Amount
(established)
10. Transaction Amount
(liquidated)
11. Transaction Amount
(uncollectible)
12. Removed Amount
13. Balance at End of
Report Quarter

B (subpop 4.7-4.8, 4.15-4.16),
and the EAN, ERQ (cont.) or
Due Date (reimb.), and balance
are identical in two or more
records, all of those records are
rejected.

R (subpops 4.5-4.6, 4.13-4.14),
and the EAN, ERQ (cont.) or
Due Date (reimb.), and removed
amount are identical in two or
more records, all of those
records are rejected.

L or U (subpops 4.2-4.4 and
4.10-4.12), and the EAN,
transaction date, ERQ (cont.) or
Due Date (reimb.), transaction
type, and transaction amount are
identical in two or more records,
all of those records are rejected.

E (subpops 4.1 and 4.9), and the
EAN, transaction date,
established date, ERQ (cont.) or
Due Date (reimb.), and amount
established are identical in two
or more records, all of those
records are rejected.

If the transaction type is:

Data Validation
Duplicate Detection Rule
Applied to Extract File

5/7/07

Currently, the UI Tax DVWS does not
check for duplicates in Population 4.
State IT staff now are responsible for
ensuring that the extract file does not
include duplicate transactions.
DVWS 1.1 will be modified to include
the new duplicate detection criteria.

Comments

DUPLICATE DETECTION CRITERIA

UI Tax Validation Handbook

Each field audit
counted once.

5. Field Audits

should

ETA 581 Reporting Rule

Population

TABLE E.1 (continued)

APPENDIX E

E.5

3. Audit ID Number

Relevant Data
Elements from Extract
File (by Field
Number)
2. EAN
If the EAN and Audit ID
Number are identical in two or
more records, all of those
records are rejected.

Data Validation
Duplicate Detection Rule
Applied to Extract File

Comments

5/7/07

DUPLICATE DETECTION CRITERIA

APPENDIX F
RECORD LAYOUTS

APPENDIX F

RECORD LAYOUTS

EXPLANATION OF UI TAX DATA FORMATS
There are 6 types of data formats referred to in Appendix A and Appendix F.
1.

Required. These fields cannot be blank. They may be mandatory codes, dates or
dollar values. Required cells in Appendix A tables indicate the required code, date,
or dollar value parameters, or display the word “Required.”
Required text fields have code values that must be entered, such as A, C, R, etc. All
of the allowable generic values for each field are listed in the Data Type/Format
column on the record layout. The generic values must be followed by a dash and the
corresponding state-specific value.

Conditionally required. Data are included in these fields if the data are present in
the state’s system. Applies to date and wages fields.

Optional. These fields are gray in Appendix A and the word “Optional” is displayed.
The software does not look at these fields at all. Any values can be entered or they
can be left blank.

Must be blank. These are text or date fields where the presence of data indicates an
error. Therefore, they must be left blank (such as population 4 transaction date for
balance subpopulations 4.7, 4.8, 4.15, and 4.16).

Must be blank or 0. These are numeric fields where the presence of data other than
0 indicates an error. In tax these are primarily wages fields in populations 4 and 5.

System generated. These fields are generated by the DV software and data should
not be placed in these fields in the extract files. These fields are primarily time lapse
and age fields.

Some values are abbreviated in the record layouts (Appendix F) but are shown in the
report validation specifications (Appendix A) in their entirety for informational purposes.

UI Tax Validation Handbook

F.2

5/7/07

APPENDIX F

RECORD LAYOUTS

Notes:
For most steps referenced in Appendix A column headers, Rule 1 is the indicator in the
state system. However, if a state does not maintain the indicator specified in Rule 1, then
the state programmer must review the other rules in that step in order to develop the
required validation logic.
The extract file type is ASCII, comma delimited. Data must be in the order listed in the
record layouts.

UI Tax Validation Handbook

F.3

5/7/07

RECORD LAYOUT FOR POPULATION 1

RECORD LAYOUTS

EAN

Employer Status Indicator

Employer Type

Liability Date (Met
Threshold)

UI Tax Validation Handbook

OBS

Field Name

No.

Step 14

Step 2A
Step 2B

Step 3A

Step 1A

Module 3 Reference

F.4

Indicate the most recent
date on which the
employing unit met the
State law definition of a
newly established or
successor employer.

Indicate whether the
employer type is
contributory or
reimbursable.

Indicate that the
employer is an active
employer.

Employer Account
Number

Assign to each record.
Use sequential numbers
starting at 1.

Field Description

Date - MM/DD/YYYY
(Required)

Text – C
R
(Required)

Text - A
(Required)

Number - 000000000
(Required)

Number - 00000000
(Required)

Data Format

Example: If the state-specific code for an Active Employer is 01, then the data format would be A-01.

DATE

CHAR (20)

INTEGER

Data Type

NOT NULL

Constraint

5/7/07

The record layout provides the format for the validation extract file. The extract file type must be ASCII, comma delimited columns. Data must be in the order listed
in the record layout. The Data Format column indicates the generic values for text fields. These must be followed by a dash and the state-specific value. The
Module 3 reference indicates the step where the state-specific values are documented.

APPENDIX F

Inactive/Terminated "as
of" Date

Activation Processing
Date

UI Tax Validation Handbook

Reactivation Processing
Date

Field Name

No.

APPENDIX F

Step 15

Step 5

Step 16

Module 3 Reference

F.5

Indicate the date on
which an account was
established on the
State’s system for an
'employer,' under the
State unemployment
compensation law.

Indicate the effective date
for the termination or
inactivation status of the
employer.

Indicate the date on
which an employer
account was updated on
the State's system to
reflect the reactivation of
a previously inactivated
or terminated employer.

Field Description

Date - MM/DD/YYYY
(Required)

Date - MM/DD/YYYY

Data Format

RECORD LAYOUT FOR POPULATION 1

DATE

Data Type

NOT NULL

Constraint

5/7/07

RECORD LAYOUTS

Wages in Quarter 1

Wages in Quarter 2

UI Tax Validation Handbook

Number of Liable
Quarters

Field Name

No.

APPENDIX F

Step 7A

Step 7B

Module 3 Reference

F.6

Total wages for the
employer in the second
quarter prior to the report
quarter. Enter 0.00 for
either zero wage reports
or reports that weren't
filed.

Total wages for the
employer in the quarter
prior to the report quarter.
Enter 0.00 for either zero
wage reports or reports
that weren't filed.

Indicate the number of
consecutive quarters
between the date the
employer was activated
or reactivated on the
State’s system and the
quarter prior to the report
quarter being validated.
If the number of liable
quarters is eight or more,
the value should be
reported as eight. If the
employer was activated
or reactivated during the
report quarter, then the
number of liable quarters
is zero.

Field Description

Number0000000000000.00
(Conditionally Required)

Number – 0
1
2
3
4
5
6
7
8
(Required)

Data Format

RECORD LAYOUT FOR POPULATION 1

DECIMAL
(15,2)

INTEGER

Data Type

NOT NULL

Constraint

5/7/07

RECORD LAYOUTS

Wages in Quarter 3

Wages in Quarter 4

Wages in Quarter 5

Wages in Quarter 6

UI Tax Validation Handbook

Field Name

No.

APPENDIX F

Step 7A

Module 3 Reference

F.7

Total wages for the
employer in the sixth
quarter prior to the report
quarter. Enter 0.00 for
either zero wage reports
or reports that weren't
filed.

Total wages for the
employer in the fifth
quarter prior to the report
quarter. Enter 0.00 for
either zero wage reports
or reports that weren't
filed.

Total wages for the
employer in the fourth
quarter prior to the report
quarter. Enter 0.00 for
either zero wage reports
or reports that weren't
filed.

Total wages for the
employer in the third
quarter prior to the report
quarter. Enter 0.00 for
either zero wage reports
or reports that weren't
filed.

Field Description

Number 0000000000000.00
(Conditionally Required)

Data Format

RECORD LAYOUT FOR POPULATION 1

DECIMAL
(15,2)

Data Type

Constraint

5/7/07

RECORD LAYOUTS

Wages in Quarter 7

Wages in Quarter 8

User Field

UI Tax Validation Handbook

Field Name

No.

APPENDIX F

Step 7A

Module 3 Reference

F.8

User defined field. Can
be used for any
additional data element.

Total wages for the
employer in the eighth
quarter prior to the report
quarter. Enter 0.00 for
either zero wage reports
or reports that weren't
filed.

Total wages for the
employer in the seventh
quarter prior to the report
quarter. Enter 0.00 for
either zero wage reports
or reports that weren't
filed.

Field Description

Text
(Optional)

Number 0000000000000.00
(Conditionally Required)

Data Format

RECORD LAYOUT FOR POPULATION 1

CHAR (100)

DECIMAL
(15,2)

Data Type

Constraint

5/7/07

RECORD LAYOUTS

RECORD LAYOUT FOR POPULATION 2

RECORD LAYOUTS

EAN

Employer Report Quarter
(ERQ)

Employer Type

Received Date

Final Assessment Date

UI Tax Validation Handbook

OBS

Field Name

No.

Step 10

Step 9

Step 2A
Step 2B

Step 1B

Module 3 Reference

F.9

Indicate the date a final
assessment becomes
legally due and
collectible.

Indicate the date of
receipt by the agency of
the contributions report
from a subject employer.

Indicate whether the
employer type is
contributory or
reimbursable.

Indicate the calendar
quarter of business
activity covered by an
employer’s contributions
report.

Employer Account
Number

Sequential number, start
at 1

Field Description

Date - MM/DD/YYYY
(Conditionally Required)

Text – C
R
(Required)

Number - YYYYQQ
(Required)

Number - 000000000
(Required)

Number - 00000000
(Required)

Data Format

Example: If the state-specific code for Contributory Employer Type is A, then the data format would be C-A.

DATE

CHAR (20)

CHAR (6)

CHAR (20)

INTEGER

Data Type

NOT NULL

Constraint

5/7/07

APPENDIX F

Liability Date
(Met Threshold)

Inactive/
Terminated "as of" Date

Suspended "as of"
Quarter

Inactivation
/Termination
Processing Date

User Field

UI Tax Validation Handbook

Liability Date (Initial or
Reopen)

Field Name

No.

APPENDIX F

Step 6A
Step 6B
Step 6C

Step 5

Step 14

Step 4A
Step 4B

Module 3 Reference

F.10

User defined field. Can
be used for any additional
data element.

Indicate the processing
date for the inactivation or
termination status of the
employer.

Indicate the specific ERQ
for which the State has
suspended the
employer’s report filing
requirement.

Indicate the effective date
for termination or
inactivation status of the
employer.

Indicate the most recent
date on which the
employing unit met the
State law definition of a
newly established or
successor employer.

Indicate the date on
which an employing unit
meets the State’s legal
definition of an employer
and is registered and
required to file reports.

Field Description

Text
(Optional)

Date - MM/DD/YYYY
(Conditionally Required)

Number - YYYYQQ

Date - MM/DD/YYYY
(Conditionally Required)

Data Format

RECORD LAYOUT FOR POPULATION 2

CHAR (100)

DATE

CHAR (6)

DATE

Data Type

Constraint

5/7/07

RECORD LAYOUTS

RECORD LAYOUT FOR POPULATION 3

RECORD LAYOUTS

EAN

Employer Type

Status Determination
Type Indicator

Time Lapse

UI Tax Validation Handbook

OBS

Field Name

No.

Step 12

Step 11A
Step 11B
Step 11C
Step 11D

Step 2A
Step 2B

Step 1C

Module 3 Reference

F.11

Place a zero (0) in this
field. (Software generates
the time lapse)

Indicate status
determination type by
New, Successor,
Inactivation or
Termination.

Indicate whether the
employer type is
contributory or
reimbursable.

Employer Account
Number

Sequential number, start
at 1

Field Description

Number – 0

Text – N
S
I
T
(Required)

Text – C
R
(Required)

Number - 000000000
(Required)

Number - 00000000
(Required)

Data Format

Example: If the state-specific code for New Status Determination is NEW, then the data format would be N-NEW.

INTEGER

CHAR (10)

CHAR (20)

INTEGER

Data Type

NOT NULL

Constraint

5/7/07

APPENDIX F

Liability Date
(Met Threshold)

End of Liable Quarter

UI Tax Validation Handbook

Status Determination
Date

Field Name

No.

APPENDIX F

Step 14

Step 13

Module 3 Reference

F.12

Indicate the last day of
the quarter in which the
employing unit met the
State law definition of a
newly established or
successor employer.
States that do not have
this should leave the field
blank; the value will then
be calculated by the
software.

Indicate the most recent
date on which the
employing unit met the
State law definition of a
newly established or
successor employer.

Indicate the date of any
recorded administrative
action that establishes,
modifies, changes,
inactivates, or terminates
an employing unit’s
liability as an employer.

Field Description

DATE

Date - MM/DD/YYYY
(Required)

Date - MM/DD/YYYY
(Conditionally Required)

DATE

Data Type

Date - MM/DD/YYYY
(Required)

Data Format

RECORD LAYOUT FOR POPULATION 3

NOT NULL

Constraint

5/7/07

RECORD LAYOUTS

Reactivation Processing
Date

Successorship
Processing Date

Predecessor Account
Number

UI Tax Validation Handbook

Activation Processing
Date

Field Name

No.

APPENDIX F

Step 18

Step 17

Step 16

Step 15

Module 3 Reference

F.13

Indicate the account
number for an employing
unit that has been
acquired by another
employer.

Indicate the date on
which an employer
account was established
or updated to reflect an
acquisition by the
employer which met the
State law definition of
successorship.

Indicate the date on
which an employer
account was updated on
the State’s system to
reflect the reactivation of
a previously inactivated
or terminated employer.

Indicate the date on
which an account was
established on the State’s
system for an 'employer,'
under the State
unemployment
compensation law.

Field Description

Number - 000000000

Date - MM/DD/YYYY

Data Format

RECORD LAYOUT FOR POPULATION 3

CHAR (20)

DATE

Data Type

Constraint

5/7/07

RECORD LAYOUTS

Inactivation Processing
Date

Termination Processing
Date

User Field

UI Tax Validation Handbook

Field Name

No.

APPENDIX F

Step 6A or
Step 6C

Step 6A or
Step 6B

Module 3 Reference

F.14

User defined field. Can
be used for any additional
data element.

Indicate the processing
date for the termination
status of the employer.

Indicate the processing
date for the inactivation
status of the employer.

Field Description

Text
(Optional)

Date - MM/DD/YYYY

Data Format

RECORD LAYOUT FOR POPULATION 3

CHAR (100)

DATE

Data Type

Constraint

5/7/07

RECORD LAYOUTS

RECORD LAYOUT FOR POPULATION 4

RECORD LAYOUTS

EAN

Employer Type

Transaction Date

Established Q/Date

Employer Report Quarter
(ERQ)

UI Tax Validation Handbook

OBS

Field Name

No.

Step 1D

Step 19B

Step 19A

Step 2A
Step 2B

Step 1D

Module 3 Reference

F.15

Indicate the calendar
quarter of business
activity covered by an
employer’s contributions
report.

Indicate the date that a
past due contribution was
entered into the system.

Indicate the date that a
transaction was entered
into the system.

Indicate whether the
employer type is
contributory or
reimbursable.

Employer Account
Number

Sequential number, start
at 1

Field Description

Number - YYYYQQ

Date - MM/DD/YYYY
(Required)

CHAR (6)

DATE

CHAR (20)

Text – C
R
(Required)
Date - MM/DD/YYYY

CHAR (20)

INTEGER

Data Type

Number - 000000000
(Required)

Number - 00000000
(Required)

Data Format

Example: If the state-specific code for Receivables Established is R, then the data format would be E-R.

NOT NULL

Constraint

5/7/07

APPENDIX F

Transaction
Type/Indicator

Amount Established in
RQ

Amount Liquidated

Amount Uncollectible

Amount Removed

UI Tax Validation Handbook

Due Date

Field Name

No.

APPENDIX F

Step 25

Step 24

Step 23

Step 22

Step 21A
Step 21B
Step 21C

Step 20

Module 3 Reference

F.16

Indicate the amount of
receivables removed
during the report quarter.

Indicate the amount of
receivables declared
uncollectible during the
report quarter.

Indicate the amount of
receivables liquidated
during the report quarter.

Number 0000000000000.00

DECIMAL
(15,2)

Number 0000000000000.00
Number 0000000000000.00

DECIMAL
(15,2)

CHAR (20)

DATE

Data Type

Number 0000000000000.00

Text – E
L
U
R
B
(Required)

Indicate the transaction
type code for receivables
established, liquidated,
declared uncollectible or
removed. Use a code of
B for records of account
balances at the end of
the RQ.
Indicate the amount of
contributions or payments
determined to be past
due during the report
quarter.

Date - MM/DD/YYYY

Data Format

Indicate the date after
which the State imposes
interest and penalty for
late payment.

Field Description

RECORD LAYOUT FOR POPULATION 4

NOT NULL

Constraint

5/7/07

RECORD LAYOUTS

Balance at End of RQ

Age of Receivable

User Field

UI Tax Validation Handbook

Field Name

No.

APPENDIX F

Step 27A
Step 27B

Step 26

Module 3 Reference

F.17

User defined field. Can
be used for any additional
data element.

Indicate the age of
receivable in days for
receivable balances at
the end of the report
quarter.

Indicate the total amount
of past due contributions
as of the last day of the
report quarter being
validated. For aging,
States should capture a
separate record for each
employer report quarter
that has a balance, rather
than an aggregate
balance.

Field Description

CHAR (100)

INTEGER

Number –
0000000000000
(Optional)

Text
(Optional)

DECIMAL
(15,2)

Data Type

Number 0000000000000.00

Data Format

RECORD LAYOUT FOR POPULATION 4
Constraint

5/7/07

RECORD LAYOUTS

RECORD LAYOUT FOR POPULATION 5

RECORD LAYOUTS

EAN

Audit ID #

Employer Size

Change Audit

Audit Completion Date

UI Tax Validation Handbook

OBS

Field Name

No.

Step 30

Step 29A
Step 29B

Step 28A
Step 28B

Step 1E

Module 3 Reference

F.18

Indicate the date the
audit was completed and
recorded or posted as
such.

Indicate whether an audit
resulted in a discovery of
wages, contributions or
employees not previously
reported.

Indicate whether the
employer size is large or
small.

Indicate the audit
identification number.

Employer Account
Number

Sequential number, start
at 1

Field Description

Example: If the state-specific code for a Large Employer is Y, then the data format would be L-Y.

CHAR (20)

DATE

Date - MM/DD/YYYY
(Required)

CHAR (20)

INTEGER

Data Type

Text – Y
N
(If field is blank, software
will determine if record
has value not equal to 0
in any one of record
layout fields 9, 10, 14, 15,
19, 20. Software will then
place a Y-DVWS in field.)

Text – L
S
(Required)

Number - 00000000
(Required)

Number - 000000000
(Required)

Number - 00000000
(Required)

Data Format

NOT NULL

Constraint

5/7/07

APPENDIX F

Total Wages Post-Audit

Total Wages UnderReported

Total Wages OverReported

Total Wages
Reconciliation Amount

Taxable Wages
Pre-Audit

Taxable Wages
Post-Audit

UI Tax Validation Handbook

Total Wages Pre-Audit

Field Name

No.

APPENDIX F

Step 32B

Step 32A

Step 31E

Step 31D

Step 31C

Step 31B

Step 31A

Module 3 Reference

F.19

Indicate the full amount of
post-audit taxable wages
for quarters audited.

Indicate the full amount of
pre-audit taxable wages
reported for quarters
audited.

Place a zero (0) in this
field. (Software generates
amount)

Indicate the full amount of
over reported total wages
discovered as a result of
the audit.

Indicate the full amount of
under reported total
wages discovered as a
result of the audit.

Indicate the full amount of
total wages recorded in
audit summaries for
audited quarters.

Indicate the full amount of
pre-audit total wages
reported for quarters
audited.

Field Description

DECIMAL
(15,2)

Number 0000000000000.00
(Optional)
Number 0000000000000.00
(Optional)

DECIMAL
(15,2)

Number – 0

Number 0000000000000.00

DECIMAL
(15,2)

NOT NULL

DECIMAL
(15,2)

Number 0000000000000.00
(Required)
Number 0000000000000.00

NOT NULL

Constraint

DECIMAL
(15,2)

Data Type

Number 0000000000000.00
(Required)

Data Format

RECORD LAYOUT FOR POPULATION 5

5/7/07

RECORD LAYOUTS

Taxable Wages
Under-Reported

Taxable Wages
Over-Reported

Taxable Wages
Reconciliation Amount

Contributions
Pre-Audit

Contributions
Post-Audit

Contributions
Under-Reported

Contributions
Over-Reported

UI Tax Validation Handbook

Field Name

No.

APPENDIX F

Step 33D

Step 33C

Step 33B

Step 33A

Step 32E

Step 32D

Step 32C

Module 3 Reference

F.20

Indicate the full amount of
over reported
contributions discovered
as a result of the audit.

Indicate the full amount of
under reported
contributions discovered
as a result of the audit.

Indicate the full amount of
post-audit contributions
reported for quarters
audited.

Indicate the full amount of
pre-audit contributions
reported for quarters
audited.

Place a zero (0) in this
field. (Software generates
amount)

Indicate the full amount of
over reported taxable
wages discovered as a
result of the audit.

Indicate the full amount of
under reported taxable
wages discovered as a
result of the audit.

Field Description

DECIMAL
(15,2)

Number 0000000000000.00

DECIMAL
(15,2)

Number 0000000000000.00
(Optional)

DECIMAL
(15,2)

Number 0000000000000.00

Number – 0

DECIMAL
(15,2)

Data Type

Number 0000000000000.00

Data Format

RECORD LAYOUT FOR POPULATION 5
Constraint

5/7/07

RECORD LAYOUTS

Contributions
Reconciliation Amount

User Field

UI Tax Validation Handbook

Field Name

No.

APPENDIX F

Step 33E

Module 3 Reference

F.21

User defined field. Can
be used for any additional
data element.

Place a zero (0) in this
field. (Software generates
amount)

Field Description

Text
(Optional)

Number – 0

Data Format

RECORD LAYOUT FOR POPULATION 5

CHAR (100)

DECIMAL
(15,2)

Data Type

Constraint

5/7/07

RECORD LAYOUTS

File Type	application/pdf
File Title	Microsoft Word - 00_UITaxHandbook_Cover_Pages.doc
Author	RRuben-Urm
File Modified	2008-05-15
File Created	2008-05-15