The ETA 227 Report: What It Is, How It - PowerPoint PPT Presentation

Loading...

PPT – The ETA 227 Report: What It Is, How It PowerPoint presentation | free to download - id: 421bb6-MTJlZ



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

The ETA 227 Report: What It Is, How It

Description:

Penalty Reporting State practice and definitional issues 227 Reporting Issues Fields where reporting errors predominate Population 12 ... court actions, ... – PowerPoint PPT presentation

Number of Views:66
Avg rating:3.0/5.0
Slides: 51
Provided by: owsDoleta
Learn more at: http://ows.doleta.gov
Category:
Tags: eta | court | report | reporting

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: The ETA 227 Report: What It Is, How It


1
The ETA 227 Report What It Is, How Its Used,
How Its Validated
  • Scott Gibbons
  • Burman Skrable

2
What and Why of the 227 Report
3
Why Burden You with the ETA 227?
  • Federal oversight of proper and efficient
    administration includes program integrity
  • Performance Measures
  • Analysis
  • Workload and Planning
  • Economic Indicators
  • Government-wide promotion of integrity

4
How Is the ETA 227 Used?
  • Monitoring of BPC by ETA staff
  • Construction of Key Performance Measures
  • Government Performance and Results Act
  • UI Performs Core measure
  • Integrity measuring by OMB, Department of Labor
    CFO and OIG
  • Benefit-Cost and similar Analyses
  • Legislative and Program Development
  • NDNH, Tax-offset programs

5
ETA 227 Content
  • Detection Establishment of Overpayments
  • Who or what caused the OPs
  • How they were detected
  • Recovery and other Reconciliation Activities
  • Criminal Civil Recovery Actions
  • Age of Overpayment Receivables

6
Section A, Overpayments Established by Cause
7
Section B, Overpayments Established by Mode of
Detection
8
Section C, Recovery/Reconciliation
9
Section D, Criminal/Civil Actions
10
Section E, Aging of OP Accounts
11
227 and the Reporting Process
12

Generating the ETA 227
  • All data on the ETA 227 should be traceable to
    data in the states financial accounting system.
  • Entries must be made for all items.
  • Amended reports - (send any changes to the ETA
    227 electronically).
  • Have 3 years to amend a report.

13
Reasons for Inaccurate Reporting
  • Poor coordination between program offices and
    reporting teams
  • Lack of accountability in the reports process
  • The three Is and Handbook 401
  • Incorrect guidance
  • Incomplete guidance
  • Imprecise guidance

14
Weighing Accuracy vs. Timeliness
  • Accuracy is ALWAYS more important than timeliness
  • If issues arise, contact us and well work with
    you to help solve the issues

15
ETA 227 Quarterly Due Dates
  • Quarter ending March 31 is due May 1
  • Quarter ending June 30 is due August 1
  • Quarter ending September 30 is due November 1
  • Quarter ending December 31 is due February 1

16
Reporting Systems and Data Integrity
  • Rules on data that can be submitted
  • Basic QA/QC sits on the front end of the
    reporting process
  • Comes in two forms Warnings and Errors
  • Transmittal depends on content

17
ETA 227 Reporting Examples of Reporting Edits
18
Troubleshooting ETA 227 Transmittal
  • It is critical that the report be reviewed by BPC
    staff before transmittal
  • The report will not transmit with empty cells
  • Please make sure that you have up-to-date changes
    in the edits for the report

19

Troubleshooting ETA 227 Transmittal
  • Please make sure you are using the current
    version of the ETA 227 (See 401 Handbook, 4th
    Edition, April 2007).
  • http//wdr.doleta.gov/directives/attach/ETAH/ETHa
    nd401_4th_s04.pdf (see IV-3-1)
  • Data edits are found in appendix C of Handbook
    402 http//wdr.doleta.gov/directives/attach/ETAH/
    ETHand402_5th_Att12.pdf (see C-13)
  • Make sure the report is actually transmitted
  • Make certain that errors are addressed
  • Warnings are for your information

20
Data Validation and the 227
21
How We Validate UI Reported Counts
  • We independently reconstruct the counts we want
    to validate
  • This involves building a record for each
    transaction that goes into those counts
  • The result is an audit trail
  • We compare the reported counts with reconstructed
    counts
  • Reported counts are valid if within a tolerance

22
Validation Process
  • Decide what must be validated
  • Design appropriate record for each type of
    transaction or status (Population)
  • Build file
  • Test file
  • Compare counts from tested file with reported
    counts

23
Validation Concepts Population
  • Population is the name DV gives to a group of
    the same type of transaction or status
  • Example Overpayments Established
  • Validation activity is organized by Population
  • Its more focused and more efficient
  • Often the same type of transaction or status
    appears in more than one report
  • Many UI reports combine multiple types of
    transactions/statuses
  • E.g., the 227 has overpayments established,
    overpayments reconciled, overpayment balances at
    end of quarter, criminal or civil actions

24
Validation Concepts Population
  • Benefits DV defines 15 distinct populations
  • These are used to validate 13 UI reports
  • DV uses three populations to validate the 227
    report
  • Tax DV defines 5 populations
  • These are all used to validate parts of the ETA
    581 report

25
Example Validating the Clue Fest
  • The Great National Clue-Fest, hundreds of teams
    from throughout the U.S. play Clue to determine
  • Who murdered John Boddy?
  • Col Mustard, Prof. Plum, Mr. Green, Mrs. Peacock,
    Miss Scarlet, or Mrs. White?
  • What were the circumstances of his death?
  • What was the weapon?
  • In what room was he killed?

26
Validating the Clue Fest (continued)
  • Monthly reporting by all teams
  • Counts on 288 (6x6x8) possible outcomes
  • Teams are told to retain for possible validation
  • Game sheets containing result, date of game, team
    name
  • You must validate

27
Validating the Clue Fest (continued)
  • You design the Clue Data Record
  • Team name/ID
  • Date of game
  • Murderer
  • Weapon
  • Room
  • You select teams to code individual results into
    your record
  • You spot-check some records against game sheets
  • You enter results into Clue-DV software
  • DV software compares validation counts against
    reported counts

28
Validating the 227
  • What should be validated?
  • Section A (Numbers and Dollars of Overpayments
    established, by Cause)
  • Population 12, Overpayments Established
  • At some point may include B. Mode of Detection
  • Section C (Recovery/Reconciliation)
  • Population 13, Overpayment Reconciliation
    Activities
  • Section E (Aging of Overpayment Accounts)
  • Population 14, Age of Overpayments

29
Validating the 227
  • Designing the extract file
  • The file is to have a record for every countable
    transaction or status for the report cells
    validated
  • To classify each record into one of the report
    cells, that data record must have a field for
    each classifying dimension
  • Its like the game of Clue

30
Validating the 227
  • Population 12 Extract File Record
  • Individual ID (SSN, each OPs unique ID)
  • Program Type
  • Type of OP (Fraud, Non-fraud)
  • OP Cause (Multi-claimant schemes, Claimant,
    Employer, SESA, Reversals, Other)
  • Detection Type
  • Date Established
  • UI Amount
  • Federal Amount

31
Validating the 227
  • Population 13 Extract File Record
  • Individual OP ID (SSN, each OPs unique ID)
  • Program Type (UI or UCFE or UCX)
  • OP Type (Fraud, Non-fraud)
  • Type of Reconciliation Activity (Cash, Benefit
    Offset, etc.)
  • Date of Reconciliation Activity
  • UI Amount
  • Federal Amount

32
Validating the 227
  • Population 14 Extract File Record
  • Individual OP ID (SSN, each OPs unique ID)
  • Program Type (UI or UCFE or UCX)
  • Date Established
  • Outstanding Overpayment
  • Active Collection (Yes or No or Dropped)
  • Type of Overpayment (Fraud or Non-fraud)
  • UI Balance at End of Quarter
  • Federal Balance at End of Quarter

33
Database Elements, Subpopulations, and Report Cells Validated Populations 12, 13, 14 Database Elements, Subpopulations, and Report Cells Validated Populations 12, 13, 14 Database Elements, Subpopulations, and Report Cells Validated Populations 12, 13, 14 Database Elements, Subpopulations, and Report Cells Validated Populations 12, 13, 14 Database Elements, Subpopulations, and Report Cells Validated Populations 12, 13, 14
Population Population Number of Number of Number of
No. Type of Transaction/Status State Database Elements in Extract Record Subpop-ulations Rpt Cells Validated
12 Overpayments Established 9 16 30
13 Overpayments Reconciliation 8 34 34
14 Age of Overpayments 9 16 16
34
Validating the 227
  • Build the extract file
  • Update Module 3
  • Follow File Layouts
  • Population link off Benefits software
  • DV Users Guide
  • Use Module 3 definitions and Rules as guide to
    database screens and database locations for
    correct elements

35
Validating the 227
  • Test the Extract File
  • Ensure it captures all relevant transactions
  • Examine records rejected as errors
  • Fix incorrectly-built but countable transactions
  • Eliminate uncountable transactions from file
  • Investigate samples
  • Does record use elements that are consistent with
    correct reporting?
  • If random sample fails, must rebuild file or
    correct database

36
Validating the 227
  • The extract file is the standard for judging
    reported counts when
  • All random samples pass
  • Validators and programmers are confident that it
    includes all transactions
  • When these conditions are met, go to RV
    comparison
  • Results cannot be transmitted unless random
    samples are completed

37
Validating the 227
  • Compare Validation with Reported Counts
  • Every reported count is validated
  • Pass and Fail are only judged at group level
  • All Groups must pass for Population to pass

38
Validating the 227
  • Status of Validating Overpayment Populations

39
Validating the 227
  • Percentage Distribution of Submissions, Passes
    Fails

40
227 and Performance Measures
  • How Accurate is the Detection of Overpayments
    Ratio?
  • FY 2009 Reported Rate 53.1
  • Mean Error in Failed Validations 10
  • Failed or Not Validated 77
  • Estimated true D/O ratio 49.0

41
227 Data Analysis
  • Cost-benefit calculations of BPC activity

42
227 Reporting Issues
  • Coordination between BPC staff and reporting
    staff
  • Where do errors predominate?
  • Penalty Reporting
  • State practice and definitional issues

43
227 Reporting Issues
  • Fields where reporting errors predominate
  • Population 12 (125 errors in 480 cases)
  • Overpayment cause 29
  • Date Established - 26
  • Detection Type -- 19
  • Amount -- 16

44
227 Reporting Issues
  • Fields where reporting errors predominate
  • Population 13 (79 errors in 360 cases)
  • Type of Reconciliation Activity 52
  • Amount Errors -- 18
  • Type of Overpayment -- 17
  • Date of Reconciliation Activity 11

45
227 Reporting Issues
  • Fields where reporting errors predominate
  • Population 14 (50 errors out of 160 cases)
  • UI Amount 34
  • Date Established 32
  • Active Collection Status 18
  • Outstanding Overpayment 12

46
227 Reporting Issues
  • Penalty Reporting
  • In case of fraud, some states assess as penalty
    future weeks claimed
  • Claimant must claim and serve the weeks as
    otherwise eligible but is not paid
  • Reporting
  • Overpayments Established, when served, report on
    line 109 of Section A, Penalty
  • Reconciliation Report in Columns 13 or 14,
    Nonfraudbut in no specific section
  • Eight States reported Penalty in 2007, 2008, 2009

47
227 Reporting Issues
  • Conditional overpayments
  • State makes payments while issue is pending
  • Adjudication hearing
  • Claimant fails to appear
  • OP establishedReported as Established
  • OP reversed on redetermination
  • State reports as Subtraction even if
    establishment, reversal are within same quarter
  • Result very high Detection of Overpayments Ratio

48
227 Reporting Issues
  • OPs Established and then Subtracted in the same
    quarter may be inflating the D/O ratio
  • Subtracted/ Overpaid in states with
  • D/O Ratio over 100 20.3
  • D/O Ratio under 100 5.2

49
For Further Information
  • Scott Gibbons
  • (202) 693-3008
  • Gibbons.Scott_at_dol.gov
  • Burman Skrable
  • (202) 693-3197
  • Skrable.Burman_at_dol.gov
  • DV Web page http//ows.doleta.gov/dv/

50
End of Presentation
About PowerShow.com