Bindinglaw

US · guidance

CMS Pub. 100-04, ch. 28, § 70.6.3

Coordination of Benefits Agreement (COBA) Eligibility File Claims Recovery

activein force · 2026-08-25 – presentas-observed

Process

(Rev. 10638; Issued: 03-09-21; Effective: 04-05-21; Implementation: 04-05-21)

Effective January 2, 2007, when the CMS or the BCRC determines that 1) certain members on a COBA

production trading partner’s eligibility file were not properly loaded to the Common Working File (CWF)

Beneficiary Other Insurance (BOI) auxiliary file (see §70.6 of this chapter for more details regarding this

file) or 2) a COBA production trading partner’s claims selections, as conveyed via the COBA Insurance File

(COIF), were not properly loaded to the CWF, the CMS shall send the A/B MAC crossover contact(s) and

associated Virtual Data Center (VDC) a ‘COBAProcess’ e-mail communication. When the CMS sends a

“COBAProcess” e-mail communication to an A/B MAC to initiate a COBA eligibility file claims recovery

process, the A/ B MAC shall acknowledge receipt of the communication via return e-mail within 1 business

day. The CMS will then contact the A/B MAC’s crossover staff and associated VDC either via phone or e-mail to discuss the specific Common Working File (CWF) date span (i.e., process date) or claim date of

service parameters, or both, for the claims recovery process. Additionally, CMS will specify which specific

MAC(s), by state, will be involved in the COBA claims recovery activity. (NOTE: DME MACs and their

shared system may be required to implement the COBA eligibility file claims recovery process as part of a

future instruction.)

Following the telephone discussion between the CMS and the A/B MAC crossover staff, the COBA

eligibility file recovery process will further unfold as detailed below.

1. Receipt and Processing of the BCRC COBA Eligibility File and Searching Claims History for the

Needed Claims

Until April 5, 2021, as part of an active COBA claims recovery, the two VDCs that support the A/B MACs

shall complete an Electronic Transmittal Form (See Attachment A at the conclusion of this section) on behalf

of their associated MACs that are participating in a COBA claims recovery process. (Note: The COBA E01

eligibility file contains specifications on the COBA trading partner and the individuals whose claims need to

be recovered.)

Effective April 5, 2021, the VDCs shall be prepared to accept the following modified dataset names for the

COBA E01 Eligibility File as received from the CMS BDC:

Perspecta VDC Part A Recovery E01 Eligibility File: ASH0.FISP.HBADR.GHI.FSSFCOBE(+1)

Perspecta VDC Part B Recovery E01 Eligibility File: B999.MCSP.HBXDR.AR99RCVR(+1)

Companion Data Services (CDS) VDC Part A Recovery E01 Eligibility File:

ASP2.FISP.NDM.FSSFCOBE(+1)

CDS VDC Part B Recovery E01 Eligibility File: B999.MCSP.HBXDR.AR99RCVR(+1)

Through the COBA claims recovery process, the COB&R system supporting the BCRC sends the appropriate

VDC a copy of the trading partner’s COBA eligibility file(s), which will be prepared in accordance with the

CMS proprietary format. (Note: The COB&R system supporting the BCRC will transmit the COBA

eligibility file to the VDC through its existing Connect: Direct connection.) The VDC then notifies the

affected A/B MAC(s) that the COBA recovery eligibility file is available so that the A/B MAC(s) may

initiate a claims recovery.

Effective April 1, 2019, the shared systems supporting the A/B MACs shall accept either a Health Insurance

Claim Number (HICN) or Medicare Beneficiary Identifier (MBI), as reported via the COBA E01 eligibility

file, in the field defined as “Beneficiary Medicare ID” (file displacement 64—75).

The A/B MAC shall initiate recovery of the processed claims by systematically going against its online

claims history that meet the beneficiaries’ eligibility dates, as provided on the BCRC eligibility file(s), and

that fall within the specified CWF date span (i.e., process date) or date of service parameters, or both, that

CMS has provided to the A/B MAC.

In performing the COBA claims recovery, MACs shall not attempt to recover claims that were previously

transmitted to the BCRC. "Previously transmitted claims" may be identified by the claims' crossover

location status or the presence of the COBA ID being used for the recovery process along with a "P"

(production) indicator in association with the processed claims.

Additionally, the MAC shall not apply the COBA trading partner's selection criteria, as found on the Health

Insurance Master Record (HIMR) COBS, when recovering claims.

2. Time Frames for Recovery

The A/B MAC shall complete its claims recovery process, culminating with transmission of the recovered

claims to the COB&R system supporting the BCRC, within eight (8) work days following the date that it

receives the BCRC COBA eligibility file or as soon as possible thereafter as CMS directs.

3. Using Data Elements from the COBA Eligibility File For the Claims Recovery Process and

Copying Elements from That File to the Recovered Claims Flat File

A/ B MACs shall perform the following activities related to the COBA eligibility file:

a) Utilize each beneficiary’s coverage dates from the COBA eligibility files (file

displacement 121—128 for beneficiary supplemental eligibility-from date and file

displacement 129—136 for beneficiary supplemental-to date); and successive eligibility-from and eligibility-to dates if provided);

b) Apply the specified CWF date span; or

c) Apply the date of service parameters; or

d) Both items b and c above.

Once the A/B MAC, working with the VDC as necessary, has recovered the specified claims, it shall copy

the COBA ID from the BCRC COBA eligibility file and place it within the NM109 segment of the 1000B

loop of the flat file containing the recovered Part A and B claims.

4. Using Data Elements from the COBA Eligibility File For the Claims Recovery Process and

Copying Elements from That File to the Recovered Claims Flat File

A/ B MACs shall perform the following activities related to the COBA eligibility file:

e) Utilize each beneficiary’s coverage dates from the COBA eligibility files (file

displacement 121—128 for beneficiary supplemental eligibility-from date and file

displacement 129—136 for beneficiary supplemental-to date); and successive eligibility-from and eligibility-to dates if provided);

f) Apply the specified CWF date span; or

g) Apply the date of service parameters; or

h) Both items b and c above.

Once the A/B MAC, working with the VDC as necessary, has recovered the specified claims, it shall copy

the COBA ID from the BCRC COBA eligibility file and place it within the NM109 segment of the 1000B

loop of the flat file containing the recovered Part A and B claims.

4. Scope of the Claims Recovery Effort

Neither the A/B MAC nor its VDC shall be required to search archived claims history while fulfilling the

COBA eligibility file claims recovery process.

The A/ B MAC and its VDC shall not be required to apply the COBA production trading partner’s selection

criteria before transmitting the recovered claims to the BCRC.

The A/B MAC or its VDC shall not transmit claims that had previously been sent to the BCRC as part of the

COBA eligibility file claims recovery process, as demonstrated by the claims’ crossover location status or

the presence of a COBA identification (ID) number accompanied by a ‘P’ (production) indicator in relation

to the processed claims.

5. Populating a Unique BHT-03 Identifier to Designate Recovered Claims

The A/ B MAC shared systems shall be required to populate an ‘R’ indicator in the 22nd position of the

Beginning of the Hierarchical Transaction (BHT)-03 segment of the ASC X12 837 flat file when

transmitting recovered claims for COBA production trading partners to the BCRC. (NOTE: The CMS

would only consider invoking the COBA eligibility file recovery process for trading partners that are in

production mode. Therefore, this practice does not conflict with previous guidance issued by the CMS,

which may be referenced in §70.6.1 of this chapter.)

6. Preparation and Transmission Requirements

The recovered claim files shall be prepared in the same ASC X12 837 flat file format used for normal, daily

transmissions to the COB&R system in support of BCRC, as discussed in §70.6 of this chapter.

Effective April 5, 2021, in transmitting the recovered claims to the CMS BDC (which, in turn, transmits the

files to the COB&R system in support of the BCRC), the VDCs shall transmit the claims via a separate ASC

X12 837 flat file transmission using the modified EFT dataset names shown below.

• P/T#EFT.ON.COBA.PA.Cxxxxx.RCV.Dyymmdd.Thhmmsst [For 837 Institutional Claims]

• P/T#EFT.ON.COBA.PB.Cxxxxx.RCV.Dyymmdd.Thhmmsst [For 837 non-DMEPOS Professional

Claims]

Note the following definitions apply to the dataset names above:

• P/T – “P” = Production; “T”=Test

• Cxxxxx = C + the 5-digit MAC ID; e.g, C12302

• Dyymmdd.Thhmmsst = Current date and Time concatenated to literals D and T.

The VDCs shall send no more than 100,000 recovered claims (which equates to 20 ST-SE envelopes per

A/B MAC with 5,000 claims per envelope) to the COB&R system supporting the BCRC per transmission.

7. Marking Claims History To Assist Customer Service Efforts

When the VDC transmits the recovered claims to the COB&R system supporting the BCRC, the A/B MAC

shall mark its claims history to indicate that each claim was recovered and transmitted to the BCRC to be

crossed over to the COBA trading partner.

A/B MACs shall notify their customer service representatives that they will be able to determine that

recovered claims were sent to the BCRC by referencing claims history.

8. BCRC Detailed Error Report Processes In Relation to the Claims Recovery Process

If A/B MACs receive BCRC Detailed Error Reports that contain a 22-byte BHT-03 identifier that ends with

an ‘R,’ they shall suppress generation of provider letters, regardless of the error source code indicated

(‘111,’ ‘222,’ or ‘333’).

When the A/B MAC, or its shared system, receives BCRC Detailed Error Reports for recovered BCRC

Detailed Error Reports for recovered claims that contain ‘111,’ ‘222,’ or ‘333’ errors, it shall mark its claims

history to indicate that the recovered claims will not be crossed over.

9. The Possibility of Repairing COBA Recovery Claims

A/B MACs, and their shared systems, shall assume that recovered claims for COBA production trading

partners that exceed established percentage parameters for ‘111,’ ‘222,’ and ‘333’ errors are potential

candidates for the COBA repair process, as provided in §70.6.2 of this chapter.

In accordance with the full claim file repair process discussed in 70.6.2 of this chapter, A/B MACs and their

shared systems shall populate an ‘18’ Beginning of the Hierarchical Transmission (BHT)-02 transaction set

purpose code at the ST-SE envelope level when transmitting the ‘repaired’ COBA recovery claims.

Unlike the process documented in §70.6.2 of this chapter, A/B MACs shall transmit ‘repaired’ COBA

recovery claims to the COB&R system supporting the BCRC via the separate ASC X12 837 flat file

transmission for recovery claims, as described within "Preparation and Transmission Requirements” above.

In addition, unlike the existing full claim file recovery process documented in §70.6. 2 of this chapter, A/B

MACs and their shared systems shall include an ‘R’ in the 22nd position of the BHT-03 identifier when

transmitting the ‘repaired’ COBA recovery claims to the COB&R system supporting the BCRC.

A/B MACs, or their shared systems, shall also not generate provider notification letters if they, in

conjunction with CMS, determine that the recovered claims that contained severe errors cannot be repaired.

10. COBA Claims Recovery Financial Management Processes

The CMS will reimburse the A/B MAC for individual claims accepted by the trading partner at the current

per claim rate.

The A/B MACs’ shared systems shall develop a separate report for their associated A/B MACs to enable

them to fulfill the foregoing requirements. The shared systems shall create reports that will provide MACs

with the count of recovered claims per cycle.

Attachments A and B Relating to the COBA Claims Recovery Process

Special note: With the modernization of the Electronic Files Transfer (EFT) process used for COBA, the

A/B MACs and their associated VDCs will no longer need to complete the Electronic Transmittal Form

(Attachment) A, as included below, prior to initiating a COBA claims recovery process effective April 5,

2021.

Attachment A

ELECTRONIC TRANSMITTAL FORM

Project: Coordination of Benefits Agreement (COBA)

Task: COBA Claims Recovery Process

Contact Information

Company Name: __________________________

Contact Name: ______________________________ Phone# ___________ ext. _

Contact Email Address: ______________________________________________

CMSNet Information

Account ID:___________________ Node ID: ________________

IP Address: ___________________ Port: ____________________

Production Requirements

Filename(s): _______________________________________________________

Special Instructions (e.g., file triggers):

Test Requirements

Filename(s):

Special Instructions (e.g., file triggers):

Attachment B

COBA Eligibility File

Table 1: COBA Eligibility E01 Record Layout Header – E00

Data Element Description Field

Length

MO Field

Location

HEADER RECORD

TYPE

Value -E00 3X O E00.001

HEADER COBA ID COBA ID assigned by the COBC

Field is 9 position, alphanumeric (no

special characters), left justified, last

four positions are spaces.

Mandatory.

9X O E00.002

HEADER CREATION

DATE

Date the record was created; format:

(CCYYMMDD), with no special

characters

8X O E00.003

HEADER BENEFICIARY

STATE CODE

Beneficiary State of residence

NOTE: This field will not be

used by the COBA Process.

2X O E00.004

FILLER Blank Field. Value is spaces. 178X O E00.005

Table 2: COBA Eligibility E01 Record Layout

File attributes:

Format: Fixed block

Length: 200 bytes

Data Field Length Type Displacement Description

Record type 3 Alpha-Numeric 1–3 Type of Record Set to ‘E01’.

Mandatory

COBA ID 9 Alpha-Numeric 4-12 Coordination of Benefits

Agreement Identification

Number Field is 9 position,

alphanumeric (no special

characters), left justified, last

four positions are spaces.

Mandatory

File Effective Date 8 Alpha-Numeric 13-20 Effective date of file in

CCYYMMDD format with no

special characters.

Mandatory

Data Field Length Type Displacement Description

File Update Indicator 1 Alpha-Numeric 21 Type of update values:

‘A’ = Add

‘C’ = Change/Update

‘D’ = Delete

Required as of March

1, 2007

*Beneficiary Surname 20 Alpha-Numeric 22-41 Beneficiary last name

Mandatory

Uppercase characters only

*Beneficiary First 12 Alpha-Numeric 42-53 Beneficiary first name.

Mandatory

Uppercase characters only

Beneficiary Middle

Initial

1 Alpha-Numeric 54 Beneficiary middle initial.

Optional

Uppercase characters only

*Beneficiary Birth Date 8 Alpha-Numeric 55-62 Beneficiary date of birth in

CCYYMMDD format with no

special characters.

Mandatory

*Beneficiary Sex Code 1 Alpha-Numeric 63 Beneficiary sex code values

are: ‘M’ = Male ‘F’ = Female

NOTE: If unknown, default to

‘M’

Mandatory

Uppercase characters only

Beneficiary Medicare

ID

12 Alpha-Numeric 64-75 Beneficiary Medicare ID

(Medicare Health Insurance

Claim Number [HICN] or

Medicare Beneficiary

Identifier [MBI]).

Mandatory

Beneficiary

Supplemental ID

Number

25 Alpha-Numeric 76-100 Supplemental ID on file with

sender. Should be the same

as what is submitted on the

claim.

Optional

Beneficiary Group

Policy Number

20 Alpha-Numeric 101-120 Supplemental policy number

on file. Should be the same as

what is submitted on the claim.

Optional

Beneficiary

Supplemental Eligibility

From Date-1

8 Alpha-Numeric 121-128 Medicare supplemental

“from” date in CCYYMMDD

format with no special

characters.

Mandatory

Data Field Length Type Displacement Description

Beneficiary

Supplemental

Eligibility To Date-1

8 Alpha-Numeric 129-136 Medicare supplemental “to”

date in CCYYMMDD

format with no special

characters NOTE: This is

the coverage through

date. Indicate zeros for

open-ended dates.

Mandatory

Filler 64 Alpha- Numeric 137-200 Unused Field – Populate

with spaces

Table 3: COBA Eligibility E01 Record Layout Trailer Record – E99

Data Element Description Field

Length

MO Field

Location

Record Type Value is 'E99'. 3X M E99.001

E01 Record Count Total number of E01 records in this file. 7N M E99.002

Filler Blank Field – Value is spaces 190X M E99.003

History

(Rev. 10638; Issued: 03-09-21; Effective: 04-05-21; Implementation: 04-05-21)

Provenance

Source
cms.gov
Retrieved
2026-08-25
Edition
iom-2026-08-25
Content hash
5e03c45c105fc5167b7369661e2035a295a02f127180bf573b40efb4b672a2ff
View the official source →

The link goes to the issuing authority’s own document — the one we read to produce this record. Where a source publishes whole titles rather than sections, your browser may need a moment to jump to the provision.

Unofficial copy of government-published law, reproduced from official sources with full provenance. Not an official publication; verify against official sources before relying on it in a filing. Records in the 'guidance' corpus, and only that corpus, are sub-regulatory (interpretive guidelines, survey procedures) and are not binding law. Validity bounds follow each jurisdiction's declared temporalBasis.

Coverage · API docs

Bindinglaw

Point-in-time US law with the receipt attached. Source URL, retrieval time, content hash, and validity dates on every answer.

curl api.binding.law/v1/law/coverage

© 2026 binding.law · a Jubal, Inc. productAttorneys and firms never pay. Ever.