835 Billing..Electronic Remittance Guide

Billing Guide
CoCentrix, INC.
PRO-FILER
HIPAA Electronic Remittance

(835) Import
HIPAA File
Imports
Updated: 5/1/2015
TABLE OF CONTENTS
Table of Contents...................................................................................... 1
General Information..................................................................................3
ERemit Components:.................................................................................3
ERemit Processing Choices:.......................................................................3
Definitions of Applied Transactions:..........................................................3
Definitions of Other Stored EOB/Remittance Advice Data:..........................4
Installation Instructions............................................................................. 5
Processing Steps....................................................................................... 6
STEP 1: Parsing the Reittance File.............................................................8
Remit Parse Engine Connection: (One Time Process)............................................................8
Creating the Remit Batch: (Parsing the Remittance File)..........................................................9
Electronic Remittance Batch Form...................................................................................... 14
Remit Batch Tab.................................................................................................................. 15
Claims Tab.......................................................................................................................... 21
STEP 2: Auto match Processing............................................................24

STEP 3: Manual Matching YES? Services................................................27
YES vs. YES? in ERemit Automated Matching..................................................................31
STEP 4: Manually Matching NO Services...............................................32

Possible Reasons for Non-Matched Services:.........................................................................32
Researching Non-Matched Services:...................................................................................... 32
STEP 5: Toggle Exclud Non-Matched Services........................................37

STEP 6: Auto Apply & Save...............................................................38
Step 7: Manual CorrectionS/Applications...................................................41
Working Excluded Remit Services....................................................................................... 41
Working Non-Zero Balance Revenue Lines.............................................................................41
Step 8: Work Zero Payments (Denials)......................................................43

Step 9: Reconcilliation.............................................................................44
Electronic Remittance Reports.................................................................45
Deleting Pending Electronic Remittance Batches.......................................46
Trouble Shooting.....................................................................................48
Manually Matching an Auto-Matched Service............................................48
Correcting Complete ERemit Batches....................................................48
Adjustment Type Cross-References...........................................................49
Transfer Type Cross-References................................................................52
Page 1
Release Date: 1/1/2013
Electronic Remittance
Billing Guide
COB Data Storage.................................................................................... 55

COB Data in the ERemit Batch..................................................................55
COB Data is Stored at the Billing Line Level..............................................56
COB Data in ERemit Reports.....................................................................57
Page 2
Billing Guide
GENERAL INFORMATION
This guide is intended to explain Pro-FilerTM Classics Electronic Remittance (ERemit)
functionality; the process of parsing an 835 Electronic Remittance file into Pro-Filer TM Classic. A
brief explanation of an 835 file is given as well as detailed instructions on how and where COB
data (Claim Adjustment Reason Codes, Remark Codes, Allowed Amounts, etc.) is stored. A
review of payment, adjustment & transfer application options available with ERemit use will
also be covered.
EREMIT COMPONENTS:
1.
2.
3.
4.
5.
6.
7.
8.
HipaaParseSetup.zip file
HIPAA Parse Scripts (as needed)
Electronic Remittance Batch Report (.zip file)
Electronic Remittance Application Report (.zip file with .sql script)
ERemit Batch Information Report (.zip file with .sql script)
Electronic EOB Report (.zip file with .sql script)
Electronic Remittance Find Queries (.doc file)
5010 837 Active Report for Secondary Electronic Claims after Electronic Remittance
processing
EREMIT PROCESSING CHOICES:

1.
2.
3.
4.
5.
Payments Only
Payments and Adjustments Only (Adjustments are user defined.)
Payments and Transfers Only (Transfers are user defined.)
Payments, user defined Adjustments and user defined Transfers
Delete Pending ERemit Batches and their associated Payment records
DEFINITIONS OF APPLIED TRANSACTIONS:

Each Payment within a file is contained within a Remit Service record. These Remit Service
records are matched (both automatically and manually) within a Pro-Filer Electronic
Remittance Batch to a Pro-Filer Revenue Line (for the Payor being processed). After
processing, all matched records will contain an applied Payment transaction.
Adjustments reported in the 835 Remittance File are contained in the CAS segment of each
remit record. (See Federal list of Claim Adjustment Reason Codes.) Adjustments will only
occur for the 835 codes that have been Cross-Referenced within the Pro-Filer Table
Maintenance Adjustment Type records. (See example Cross-Reference set-up at the end of
this document.)
The Electronic Remittance Program (ERemit) is able to: 1) Apply user-defined Transfers based
on specific types of CAS records (set up, just like user-defined Adjustments, through Cross
References on Table Maintenance Transfer Type records) and/or 2) Transfer the greater than
Page 3
Billing Guide
zero balances, after application of Payments, Adjustments and user-defined Transfers, of each
matched Revenue Line to the next Payor (or Self-Pay) attached to the recorded service.
DEFINITIONS OF OTHER STORED

EOB/REMITTANCE ADVICE DATA:
AMT Coordination of Benefit (COB) Data: The AMT segments within the incoming 835
remittance file represent either Claim Level Payment Information (if reported in the 2100
Loop) or Service Level Payment Information (if reported in the 2110 Loop). Some examples
of the COB Data returned and stored are: Allowed Amount (B6); Per Day Limit (DY); Deduction
Amount or Late Filing Reduction (KH).
CAS Coordination of Benefit (COB) Data: The CAS segments within the incoming 835
remittance file represent either Claim Level Adjustments (if reported in the 2100 Loop) or
Service Level Adjustments (if reported in the 2110 Loop).
CAS data is returned in Groups (categories) of adjustments. These categories help

describe why the full billed amount has not been paid. These Group Codes include:
CO: Contractual Obligations
PR: Patient Responsibility
OA: Other Adjustments
PI: Payor Initiated Reductions
See the National Electronic Data Interchange Transaction Set Implementation Guide Health Care Claim Payment/Advice 835 ASC X12N 835 (004010X091); Page 150 for
additional information.
CAS data is further defined by Claim Adjustment Reason Codes that indicate the more
specific reasons for non-payment. Some examples of these include:
1 = Deductible;
2 = Coinsurance;
45 = Charge exceeds fee schedule;
96 = Non-covered charge(s);
B13 = Previously paid
See http://www.wpc-edi.com/codes/claimadjustment for a full listing of HIPAA Claim
Adjustment Reason Codes.
LQ Coordination of Benefit (COB) Data: The LQ segments within the incoming 835
remittance file represent the Health Care Remark Codes often used by the Payors to further
explain a returned CAS Claim Adjustment Reason Code. Some examples of these include:
M37 = Service not covered when the patient is under age 35;
M51 = Missing/incomplete/invalid procedure code(s);
MA38 = Missing/incomplete/invalid birth date; etc.
See http://www.wpc-edi.com/codes/remittanceadvice for a full listing of HIPAA Health
Care Remark Codes.
Page 4
Billing Guide
Important: The Pro-Filer ERemit program processes ALL CAS, AMT & LQ Data at the
Service Level (Loop 2110) and stores the incoming information on the matched and
applied Pro-Filer Billing Lines. This is also where the data will be pulled from for
secondary claims.
Page 5
Billing Guide
INSTALLATION INSTRUCTIONS
1. Run any .sql scripts delivered from CoCentrix, if any, against the database into which
the remittance files will be parsed in the order in which they are presented.
2. Unzip the HipaaParseSetup.zip file components into a temporary folder on the testing
server. This must be installed on the server from where it will be run, just like the 837
Active Report engines.
3. Run Setup.exe from this temporary folder. This will install the components of the tool
into C:\Program Files\Unicare\Hipaa Parse and Import folder or C:\Program Files
(x86)\Unicare\Hipaa Parse and Import folder.
4. Start Pro-Filer and create a new Report record to be run at the Billing & AR \ Electronic
Remittance tree node and to be linked to:
C:\Program Files\Unicare\Hipaa Parse and Import\HipaaParse.exe or C:\Program Files
(x86)\Unicare\Hipaa Parse and Import\HipaaParse.exe
5. Install each of the following reports using the standard Crystal Report installations.
These reports should have been delivered to your organization with the HIPAA Parse and
Import Tool. However, these reports can also be downloaded from our CoCENTRIX
website under Customer Login (requires username and password). See individual
instruction documents for required Tree Node links. (Be sure to run any accompanying
stored procedures included in the .zip files and forward the instruction documents
to the Billing & AR staf.)
Electronic Remittance Application Report
Electronic Remittance Batch Report
Payment Application Reports
Electronic Batch Information Report
Electronic EOB Report
6. Install any fix .xml files, which are created for specific Payors in specific states.
CoCentrix will only send these files if they directly relate to the Payors for which
electronic payments will be applied. These files will be accompanied with their own
instructions.
7. We highly recommend downloading the CMS (Centers for Medicare & Medicaid Services)
Easy Print (MREP) software to view and print HIPAA compliant 835 files for providers.
This software, which is available for free, is used to access and print remittance
advice information (including special reports) from HIPAA 835 format files.
It is recommended that you download this free software, prior to your ERemit training
sessions, in accordance with the Download/Installation instructions provided by CMS on
their website located at:
http://www.cms.hhs.gov/accesstodataapplication/02_medicareremiteasyprint.asp
Page 6
Billing Guide
8. Develop a plan to re-index / defrag / shrink and update the SQL statistics of your ProFilerTM database by reviewing the information provided in Knowledgebase Article KBA01341 on the CoCentrix website at: https://servicedesk.cocentrix.com/KnowledgeBase
This process is very important to maintain as your database increases in size in order to
allow maximized efficiency within the ERemit service matching processes.
Page 7
Billing Guide
PROCESSING STEPS
1. Parse the remittance file into Pro-Filer using the HipaaParse.exe Engine
Creates an Electronic Remittance Batch
Creates a Payment Entry record (linked to the ERemit batch above)
Make decision to apply Cross-Referenced Adjustments or not
Make decision to apply Cross-Referenced Transfers or not
2. Auto Match Remit Services to Pro-Filer Revenue Lines (Yes Services)
Process activated by accessing the Match button on Claims tab
Save the ERemit Batch BEFORE proceeding to manual matching
No data is saved to the database until the Save button is accessed
3. Manually match questionable matches (Yes? Services)
Identify these services using column sort options within the Claims tab
Changes the Yes? to Yes*, indicating manual intervention
4. Manually match non-matched services, where possible (No Services)
Identify these services using either column sort options within the Claims tab or
through the Electronic Remittance Batch Report options and research using the
Review Accounts form
If manual matching is possible, changes No to Yes*, indicating manual
intervention
5. Toggle Exclude all non-matched (No) Remit Services
The Apply button does not activate until all remit services have been either
matched or excluded from processing
DO NOT USE the Transfer the Balance checkbox
ALWAYS Save the ERemit Batch BEFORE proceeding to the Apply step
o No data is saved to the database until the Save button is accessed
6. Apply Payments only or Payments with Adjustments and/or Transfers
Payments are always applied
Adjustments are applied only when indicated within the parsing process (Step1)
Only Adjustments that are defined within Adjustment Type cross-references will be
applied (if activated during parsing)
Transfers that are defined within Transfer Type cross-references will also be applied
(if activated during parsing)
DO NOT USE the Transfer the Balance checkbox
Page 8
Billing Guide
7. Manually correct, apply or refund any remaining non-processed transactions contained

within the Remittance File. (These are identified through the Electronic Remittance
Batch Report.)
Run the Electronic Remittance Batch Report for Excluded records only and
research each non-zero payment record returned to determine why it was excluded
from the remittance batch processing
Voided Service: If the service was voided, the payment may need to be refunded
to the Payor
Reclassed Service: If the service was reclassed, determine if the service needs to
be re-posted and/or billed again to the Payor
Process the manual refunds, service posting, billing (create claims), and/or
transaction applications, as needed
8. Follow-up on all zero payments/denials by:
Using Medicares Easy Print software and filtering for Denials Only AND/OR
Running the Electronic Remittance Application Report for balances not equal to
zero.
This report can also be run to display the CAS & LQ codes returned that define
the denial reasons and amounts
Running the Electronic Remittance Batch Report and searching on $0.00 to
review all zero payment remit records
This report will also display the CAS & LQ codes returned that define the denial
reasons and amounts
9. Reconcile and Report transaction applications and associated stored COB data using the
Electronic EOB Report across a date range
Electronic Remittance Application Report for a given ERemit batch
Payment Application Individual Report for a given Payment record associated
with a specific ERemit batch
Important Note: Please review the instruction documents for each of the ERemit
reports for additional useful information.
Page 9
Billing Guide
STEP 1:
PARSING THE REMITTANCE FILE
REMIT PARSE ENGINE CONNECTION: (ONE TIME

PROCESS)
Install the HIPAA Parse and Import engine as described in the Installation Instructions
section of this document.
Must be installed on the Pro-Filer Client machine

Connect the HipaaParse.exe file into a Reports record in Pro-Filer following the same
guidelines for any Crystal or Active report. This report can be linked at any level on the ProFiler tree, but is recommended at the Billing & AR/Electronic Remittances folder level.
Page 10
Remittance
Electronic
Billing Guide
CREATING THE
REMIT B ATCH: (PARSING THE REMITTANCE FILE)
1. Run the HipaaParse.exe from the Electronic Remittances folder where it was linked
into Pro-Filer, using standard report functionality. Highlight the appropriate Pro-Filer
report record and click Run Report.
Page 11
Remittance
Electronic
Billing Guide
2. The HIPAA Form field should always indicate 835 for HIPAA ERemit functionality (the
Fix field should only be used upon direction from CoCentrix) and the Import Schema
field will filter by the other selections. Select Open:
Note: The HIPAA Parse & Import Tool version number will display in the upper left hand
corner of this form. This is important information when reporting ERemit issues to
CoCentrix Support.
3. Browse to the shared drive folder where the remittance files, to be processed, are stored,
highlight the appropriate file and select Open:
Page 12
Remittance
Electronic
Billing Guide
This process populates the actual file into the HIPAA Parser - 835 Healthcare Claim
Payment/Advice form. (See blue area below.)
4. Select Parse:
This process populates remittance file Loop and Segment information into the HIPAA
Parser - 835 Healthcare Claim Payment/Advice form. (See blue area below.)
Note: If the Show Parsed check box is unchecked, this area will not be displayed after
the Parse process, but it will not affect the overall ERemit functionality.
5. Select Import to Pro-Filer:

Page 13
Remittance
Electronic
Billing Guide
Hint: By copying the file name from the File to parse field before activating the
Import to Pro-Filer button, this 835 file name can be easily documented into the
associated Payment record in the next step.
Page 14
Remittance
Electronic
Billing Guide
6. The Pick Company and Payor form will display. When all fields are completed, as
desired, select OK:
Pick the Company: (Optional) Select a Company as appropriate. (This field allows the
Payment Entry record to be created and reported for a specific Company record within the
database.)
Note: If remittance payments are received for and, are to be applied across multiple ProFiler companies, do not select a Company in this form when parsing the file.
Pick the Payor: (Required) Select the Payor from which this remittance file was received from
the list presented.
Payment Type: (Required) Select the option that describes how the actual money was
received from this Payor.
Deposit Number: (Optional) Developing a deposit numbering convention will assist in the
daily reconciliation of Payment records and daily deposits. (You may wish to paste the actual
remittance file name into this field.)
Note: Current standard Pro-FilerTM Payment record reports have Deposit Number sorting
incorporated to easily reconcile all deposits entered, if the Deposit Number field is
utilized correctly. (See the Payment Entry End User Guide for additional information.)
Date Payment was Received: (Required) Enter the date the actual payment was received
by the agency. This is the date visible on the Tree View for BOTH the ERemit Batch itself and
the Payment record created with the batch. Many standard Pro-Filer TM reconciliation and
transaction reports also use the Date Received field for accurate reporting.
Page 15
Remittance
Electronic
Billing Guide
Important: The Date Payment was Received is in Fiscal Period Post Date comparisons
and calculations. (See Understanding Posted Revenue; Chapters: Fiscal Period Post
Date & Stored Posted Transaction Dates for additional detailed information.)
Check Date: (Optional) This date field may be used to track the actual date recorded on the
payment for future reference requirements. This date is not used by the system at all.
Deposit Date: (Optional) Use this field if the date the payment was deposited is different
than the current system date. This date is not used by the system at all.
Note: If the actual date the payments are deposited is the date the agency wishes to
capture for General Ledger purposes, then the date the Payment was deposited should
be reflected in the Date Payment was Received field. This will allow the system to
post the payments into reporting periods that reflect the deposit date, as reflected by
the agencys bank statements and deposit records.
Adjustments: (Optional) Use these 2 fields in conjunction with each other only if user-defined
(cross referenced) automatic Adjustments are to be applied in every instance of their
presentation.
Auto Apply Adjustments: Check this box to activate this functionality.

Adjustment Type Crosswalk: Select the appropriate Cross Reference Type used on
the Adjustment Type records.
Transfers: (Optional) Use these 2 fields in conjunction with each other only if user-defined
(cross referenced) automatic Transfers are to be applied in every instance of their
presentation.
Auto Apply Transfers: Check this box to activate this functionality.

Transfer Type Crosswalk: Select the appropriate Cross Reference Type used on the
Transfer Type records.
Note: ONLY check the Adjustments and/or Transfers checkboxes if automatic

application of adjustments and/or transfers (as defined in cross references) is desired.
See the Adjustment Type Cross-References & Transfer Type Cross-References
sections later in this document for important information about Adjustments &
Transfers set-up and functionality.
Description: (Optional, but recommended) This field is usually used to specifically identify
the Payment record that is created and will be visible from the Pro-Filer Tree View when
displaying this Payment record. You may wish to paste the actual check or EFT number or
remittance file name into this field or some other descriptor, depending on your needs.
7. When the Import process is complete, the following message will display. Select OK:
Page 16
Remittance
Electronic
Billing Guide
The HIPAA Parser - 835 Healthcare Claim Payment/Advice form will now also indicate
that the file has been imported. (See blue area below.)
8. Close the form using the Exit button in the lower right corner:
E L E C T R O N I C R E M I TTA N C E BATC H F O R M
Go to: Billing & AR/Electronic Remittances folder. Open the Electronic Remittance Batch to be
processed (use the Find feature when necessary):
Page 17
Remittance
Electronic
Billing Guide
Page 18
Remittance
Electronic
Billing Guide
R E M I T B ATC H TA B
The Remit Batch tab of the ERemit Batch form contains the following fields, many of which are
populated directly from the Remittance File.
Remit Batch Section:
Type: Format of the file that created the batch. This is only populated if reported in the
remittance file.
Original File Name: Folder name & name of file that generated the batch.
Page 19
Remittance
Electronic
Billing Guide
Batch #: Number for this batch from this Payor (assigned by the Payor) on this system date.
(If the remittance file created only 1 ERemit batch, this number will generally be a 1
preceded by zeros. In this example, the file created multiple ERemit batches and this was the
second batch from the file.)
Batch Process Status:
Pending: The batch has been created, but no transactions have been applied. Note:
The batch will remain at Pending until the Apply button is accessed and the
application process is complete.
Complete: Payments (and other optional transactions) have been applied. Note: No
further processing of this batch is possible.
Production Date: The system date on which the batch was imported into Pro-Filer (Pending)
or on which the batch went to Complete.
Provider: Displays logged-in user related to Production Date.
Remit Payment Section:
Amount: Total monetary amount for all claims/services in this batch.
Note: This amount may periodically not match the Payment Entry amount if the file also
includes Claim Level Adjustments and/or Provider Level Adjustments.
Any of the following fields are populated only if reported in the remittance file:
Method: How the funds are paid. (Check or Automated Clearinghouse, etc.)
Routing #: Bank the funds come from.
Account#: Account the funds are from.
Check #: Payor identification number for this payment.
Check Date: Date the Check/EFT was issued by the Payor.
Receiver ID: Where, or to whom, the payment is being sent.
Page 20
Remittance
Electronic
Billing Guide
Page 21
Remittance
Electronic
Billing Guide
Remit Payor Section:
Any of the following fields are populated only if reported in the remittance file:
Name: Payor Name/Code from remittance file.
Contact Name: Payor contact name.
Communication Type: Type of contact information to follow. (Telephone, E-mail, Fax, etc.)
Communication #: Telephone number(s), E-mail address, Fax number, etc.
Note: If certain fields are not populated in the above three sections, this indicates that
the file format does not contain this information, according to Federal HIPAA
Specifications.
The Remit Batch tab also contains user-defined Pro-Filer Payment information and Notes
capabilities in the following fields:
Pro-Filer Section:
Payor: This is the Pro-Filer Payor chosen during parsing. (Required)

Company: This is the Pro-Filer Company chosen during parsing.
Payment: This is the amount of the total service payments contained in the file and the
Payment Entry user-defined Received Date entered during parsing of the file. (Required)
Edit Payment: Allows the user to review, correct or add information within the Payment
Entry record that was created by the parsing & import process.
Page 22
Remittance
Electronic
Billing Guide
Page 23
Remittance
Electronic
Billing Guide
Notes:
View Match Notes: Allows the user to see information regarding the dates/times and results
of all automatic matching processes within a given batch.
Clear Match Notes: Allows the user to clear the system stored match notes displayed above.
(This is not recommended.)
Page 24
Remittance
Electronic
Billing Guide
New Form Icon in Notes Section: Allows the user to create notes for additional
information regarding the batch.
Once the note is created, its record will display within the Notes section of the Remit Batch
tab.
Page 25
Remittance
Electronic
Billing Guide
C L A I M S TA B
The Claims tab displays three separate list boxes, which provide information about the records
received within the remittance file (Remit Services) and related Pro-Filer Claims/Billing Lines
(after matching has occurred).
The Claims tab also displays information about the number of Remit Services processed and
their status (Matched, Excluded, Applied, etc.) and is where all of the ERemit program
processing takes place.
Each of these 3 list boxes can be sorted by the user by multiple column headings utilizing the
Ctrl key. (Ex: Select Client ID / Ctrl / then Service Date.)
Claims: This section provides information regarding the Remit Claims received within the
remittance file. A claim can contain one or more Billing Lines (which may also contain one or
more Services). After each ERemit process, this section will be updated with additional
matching and application information.
Page 26
Remittance
Electronic
Billing Guide
Services from Electronic Remittance: This section provides information regarding the
Remit Services (Pro-Filer Billing Lines) received within the 835 remittance file. This is Billing
Line specific information. After each ERemit process, this section will be updated with
additional matching and application information.
Example of Show All Services display: (Default). All services/billing lines received within the
remittance file will be displayed.
Example of Show Services for Selected Claim:
Only those services/billing lines contained within the highlighted claim (from the Claims list
box above) will be displayed.
Note: All manual matching will be processed through the Services from Electronic
Remittance list box.
Toggle Exclude: This functionality allows the user to exclude a claim (from the Claims list
box) or service/billing line (from the Services from Electronic Remittance list box) from the
application process.
Page 27
Remittance
Electronic
Billing Guide
Note: All non-matched services MUST be excluded before the automated payment
application process can be performed.
Matched Pro-Filer Service Revenue Lines: This section provides information regarding the
Pro-Filer Revenue Lines/Billing Lines that have been successfully matched to the parsed
remit services. This is Pro-Filer service specific information.
This section will be populated after automated matching has been completed. It will always
ONLY display records for the Remit Claims/Billing Lines that have successfully matched to ProFiler for the remitting Payor.
Preliminary matching to Clients and Claims occurs during the parsing and import processes.
Final Service/Billing Line matching occurs through the ERemit Batch Match process.
The above example displays a successfully matched Remit Claim highlighted in the Claims
list box with its Remit Service displaying in the Services from Electronic Remittance list box.
The Remit Service also has an associated (matched) Pro-Filer Billing Line, displayed in the
Matched Pro-Filer Service Revenue Lines list box.
Page 28
Remittance
Electronic
Billing Guide
Remit Service Totals Information: This section provides matching, exclusion and
application totals for the ERemit Batch. This section will be updated each time changes in the
batch occur (auto-matching, manual-matching, toggle exclude, application).
Page 29
Remittance
Electronic
Billing Guide
STEP 2: AUTO MATCH PROCESSING

Click on the Claims tab of the ERemit Batch form. Click on the Match button to activate the
automated matching process.
The Pro-Filer Status box can be accessed to display the programs process:
The Claims tab information will be updated when the matching process is complete:
Page 30
Remittance
Electronic
Billing Guide
The automated matching process evaluates the Remit Service (received from the remittance
file) for specific matching criteria in order to find a matching Pro-Filer Billing Line for the
remitting Payor.
This matching criterion includes: Pro-Filer Payor, Company, Revenue Line ID (from the
outgoing 837 Claim 6R record), Client ID, Date of Service and Procedure Code. The 1 st
& 2nd Modifiers are also used for more specified matching, if they are returned in the
835 file AND if more than one billed Pro-Filer Billing Line exists for this
Client/Payor/Company/DOS/Procedure Code combination.
Page 31
Remittance
Electronic
Billing Guide
Example of matched services:
Example of non-matched service:
Page 32
Remittance
Electronic
Billing Guide
STEP 3: MANUAL MATCHING YES? SERVICES

Sort the Remit Service list returned by the Matched column.
Remit Services that are indicated as matched Yes? have more than one possible Pro-Filer
Billing Line that they can be matched with, based on the matching variables discussed in the
previous section.
These Yes? Remit Services should be researched and manually matched to the correct ProFiler Billing Line.
Highlight the service to be manually matched. Select the open folder icon at the top right of
this list box.
The Service (Edit Existing) form will display where all manual matching of Remit Services to
Pro-Filer Billing/Revenue Lines will occur:
Page 33
Remittance
Electronic
Billing Guide
Select the Find button to display the Revenue Line matching possibilities.
Page 34
Remittance
Electronic
Billing Guide
Highlight the correct Pro-Filer record and select the Match Service button.
Page 35
Remittance
Electronic
Billing Guide
The Matched indicator will change from Yes? to Yes*, indicating that this Remit Service
has been manually matched to a Pro-Filer Billing/Revenue Line.
Page 36
Remittance
Electronic
Billing Guide
YES VS. YES? IN EREMIT AUTOMATED MATCHING

Remit Services are always received from a given Payor, for a given Client on a specified Date
with a specific Procedure Code. Some Remit Services may also include one or more Modifiers.
Electronic Remittance Matching Scenarios for Yes:
1. Remit Services received without Modifiers will match whenever the Pro-Filer
Billing/Revenue line is for the Same Payor/Company/Client, on the Same Date, with the
Same Procedure and:
One and only one billed service exists in Pro-Filer (with or without Modifiers)
More than one billed service exists in Pro-Filer, but only one exists without any
modifiers
2. Remit Services received with Modifiers will match whenever the Pro-Filer
Billing/Revenue line is for the Same Payor/Company/Client, on the Same Date, with the
Same Procedure and:
One and only one billed service exists in Pro-Filer (with or without Modifiers)
More than one billed service exists in Pro-Filer, but only one exists with the
specific modifiers returned
Electronic Remittance Matching Scenarios for Yes?:
1. Remit Services received without Modifiers will match with Yes? whenever the ProFiler Revenue line is for the Same Payor/Company/Client, on the Same Date, with the
Same Procedure and:
More than one billed service exists in Pro-Filer that exactly matches the Remit
Service (i.e. - without Modifiers)
Many Remit Services (in the same batch) are matched to one Pro-Filer Revenue
Line
2. Remit Services received with Modifiers will match with Yes? whenever the Pro-Filer
Revenue line is for the Same Payor/Company/Client, on the Same Date, with the Same
Procedure and:
More than one billed service exists in Pro-Filer with these exact same Modifiers
Many Remit Services (in the same batch) are matched to one Pro-Filer Revenue
Line
Page 37
Remittance
Electronic
Billing Guide
STEP 4: MANUALLY MATCHING NO SERVICES

Follow the procedures outlined in Step 3 to manually match Remit Services with a No
matched indicator. These services should also be researched and reviewed before proceeding
with manual matching.
POSSIBLE REASONS FOR NON-M ATCHED SERVICES:
Pro-Filer Service was Voided/Reclassed after original billing.

Service was generated from another/previous billing system.
Remittance file contained inaccurate client/service information.
RESEARCHING NON-MATCHED SERVICES:
Use the Electronic Remittance Batch Report (run for Not Matched and Not Excluded
records) to identify these non-matched services.
Use the Review Accounts form to research reasons that these reported services did not
match.
The ability to manually match services that were not matched will depend on the reason that
the service did not match automatically and on the Revenue Lines present condition.
Example:Service was voided
Non-zero payments cannot be manually matched to these services. The payment must be
manually processed to another service from the Payment Entry record associated with the
ERemit batch or adjusted off the Payment Entry record and refunded to the Payor.
Page 38
Remittance
Electronic
Billing Guide
Zero payments can be matched to voided services by accessing the Voided checkbox in the
Service manual matching form. This allows zero payments (denials) to be documented
against previous service corrections.
Example: Service was Reclassed and new posted service has not been billed
Non-zero payments cannot be manually matched to these services until the service is billed
through Claim Builder Wizard and Create Claims processes and then either manually matched
in the still Pending ERemit Batch or applied manually through Review Accounts, if the ERemit
Batch is already Completed.
Zero payments can be matched to the voided side of reclassed services by accessing the
Voided checkbox in the Service manual matching form (see above). This allows zero
payments (denials) to be documented against previously corrected services.
Example of manual matching attempt:
Use the Review AR form to review the Pro-Filer posted service:
Page 39
Remittance
Electronic
Billing Guide
This particular service was reclassed and re-posted, due to a Payor line-up change:
However, the new service has not yet been marked as billed to Medicare (the Payor the
electronic remittance file was received from):
Opening this Remit Service in the ERemit batch, will allow the user to Find all Pro-Filer
Revenue Lines that match specific Revenue Line criteria:
Page 40
Remittance
Electronic
Billing Guide
**Billed Payor; Client ID and Date of Service

However, as discovered in Review Accounts, the true matching service is not available
because it has not yet been marked as billed:
This service must be marked as billed in the system (a new claim generated) before auto or
manual matching can occur.
Note: Where appropriate the Recorded Service ID, if known, can be entered in this form
to find a specific services Revenue Line. Or the Client ID and/or Service Dates can be
edited to match to another Client or Date of Service. (This is NOT recommended, except
in very rare cases where the Payor has sent inaccurate information and the correct
information is verified.)
Upon accessing the Find button, if no matching Revenue Lines (services) are found for this
Payor/Client/DOS combination, the manual matching form will generate the following message:
Page 41
Remittance
Electronic
Billing Guide
If manual matching to previously No Remit Services is successful, the Matched flag will be
changed to Yes*, to indicate that a manual match has been made.
Very Important Notes:

Other users are able to void/reclass matched services within any Pending ERemit
Batch until the match is Saved. If this happens, the system may not process the
applied transactions successfully.
Always SAVE the ERemit Batch changes immediately after the automated Match
process.
Periodically SAVE the ERemit Batch changes during the manual matching process,
especially if performed over an extended period of time.
Page 42
Remittance
Electronic
Billing Guide
Always SAVE all the ERemit Batch changes before proceeding to the Apply
process.
Page 43
Remittance
Electronic
Billing Guide
STEP 5: TOGGLE EXCLUDE NON-MATCHED

SERVICES
After all possible manual matches are complete, use the Toggle Exclude feature to Exclude
non-matched services.
Note: Payment Application cannot be activated until all Remit Services are either
Matched = Yes (or Yes* or Yes?) or Excluded = Yes.
Highlight all of the Remit Services with a matched indicator of No and click on the Toggle
Exclude button:
The Excluded column will now indicate that these Remit Services have been excluded from
the payment application process and the Totals information will be updated:
Page 44
Remittance
Electronic
Billing Guide
The Apply button becomes available once there are NO Remit Services left as Undefined
within the Remit Services Total.
NOTE: DO NOT USE the Transfer the Balance
checkbox.
STEP 6: AUTO APPLY & S AVE

You are now ready to apply matched Payments, Adjustments and Transfers:
Transfer the Balance: DO NOT USE
Important: ALWAYS SAVE all of the ERemit Batch changes before proceeding to the Apply
process.
Apply: Upon clicking the Apply button, the automated Application process begins.
The user is given the option to continue (OK) or abort (Cancel) the process:
The Pro-Filer Status box can be accessed to display the programs process:
Page 45
Remittance
Electronic
Billing Guide
Once the process is complete, the ERemit Batch form will automatically close and the status
will be updated to Complete:
The Applied columns on the Claims tab will be updated for all Remit Claim/Services that
were matched to Pro-Filer Revenue Lines:
The Claims tab Remit Services Totals information will be updated:
Page 46
Remittance
Electronic
Billing Guide
Even though the Transfer the Balance and Apply options look active, all additional
functionality is disabled in a Complete batch.
No additional matching or transaction applications will be performed.
Page 47
Remittance
Electronic
Billing Guide
STEP 7: MANUAL CORRECTIONS/APPLICATIONS
Important: Always use the same Payment Entry record that was created during the
parsing of the file to apply any remaining transactions or to make corrections. In this
way, ALL data reported within any given 835 file transaction set will also be reported
within the same Pro-Filer Payment Entry record.
WORKING EXCLUDED REMIT SERVICES

Manually correct and/or apply any remaining non-processed (Excluded) transactions
contained within the Remittance File. These can be easily identified through the Electronic
Remittance Batch Report.
Run the Electronic Remittance Batch Report for Excluded records only and research each
non-zero payment record returned to determine why it was excluded from the remittance
batch processing.
Voided Service: If the service was voided, the payment may need to be refunded to the
Payor (along with entering a Payment Entry Adjustment into the Payment Entry record
originally created by this ERemit batch).
Reclassed Service: If the service was reclassed, determine if the service needs to be reposted and/or billed again to the Payor
Process all of the following, as needed, for all of the Excluded records within this
ERemit Batch:
Manual Refunds
Service Posting
Billing (CBW & Create Claims)
And/Or Transaction Applications:
Payments
Adjustments
Transfers
COB Data (Needed for all subsequent billing)
Note: For all additional transaction applications, always use the Payment Entry record
originally created by this ERemit batch. When all data entry is complete, the Unapplied
Balance of this Payment Entry record should equal ZERO.
WORKING NON-ZERO BAL ANCE REVENUE LINES

The goal of any payment application process is to reduce the balance of paid
revenue lines to zero. This objective is needed in order to either complete the service (paid
Page 48
Remittance
Electronic
Billing Guide
in full or paid with adjustments) or to allow subsequent billing to any remaining Client funding
sources (transfer to next Payor or to Self-Pay).
By reducing the balance of all Revenue Lines in the system to zero, where possible, the
Accounts Receivable balances will always be accurate, according to current data.
Use the Electronic Remittance Application Report to return Revenue Lines that
contain a balance not equal to zero:
Use the Electronic Remittance Application Report to return Revenue Lines that contain a
balance not equal to zero (and display COB Data) to research why the Payor Revenue
Lines involved have not yet balanced.
Manually apply any appropriate remaining Adjustments that were not

automatically applied.
Manually apply any appropriate remaining Transfers that were not automatically
applied.
Mark services for Rebill, as needed, where Payor Claim Adjustment Reasons are
not valid or can be corrected.
Balance of this Payment Entry record should still equal ZERO.
REPORTING NON-ZERO BALANCE HINTS for the Electronic Remittance Application

Report:
1. By first running the report for Services with Revenue Line Balance <> 0 and Billing
Line Detail History with Sort Group by Client will provide both Client Names & IDs and
the stored COB information in an easy to read format.
2. Running by Company a second time for Services with Revenue Line Balance <> 0
and Remit Recorded Service (Billing Line) with Sort Group by Company will allow
easier export to Excel.
3. From the Excel file generated in Step 2, Recorded Service IDs may be copied and pasted
into the Review Accounts form for easier research and manual adjustment/transfer
application.
4. Both the Review Accounts form Results list and the Payment Application forms
services grid can be sorted to follow the printed report generated in Step 1 or the Excel
output from Step 3.
Page 49
Remittance
Electronic
Billing Guide
STEP 8: WORK ZERO PAYMENTS (DENIALS)

In order to complete processing of all the information that may be contained in the incoming
835 remittance file, a follow-up of all zero payments (denials) will need to be conducted.
For MATCHED Remit Services, these can be easily identified by using the Electronic EOB
Report.
Run the Electronic EOB Report for the Received Date range desired and filter on the
Paid Amount column for $0.00 payments to review all zero payment remit records and
their reported COB information.
reasons (CARC) and additional remark codes (RARC).
Research each service for which a zero payment was received through the Review
Accounts form and the Clients record.
Take appropriate actions depending on the specific denial and Client information.
Non-Correctable Denials: Where the denied service was legitimate and no
corrective action can be taken to resubmit the service for future payment:
Adjust off the service with an appropriate Adjustment Type (using the
Payment Entry record created by this ERemit Batch).
Transfer balances to next Payors (or Self-Pay) as appropriate (using the
Payment Entry record created by this ERemit Batch).
Correctable Denials: Where the denied service and/or Client information can be
corrected and a claim resubmitted or new claim submitted:
Submit a Corrected claim through standard Pro-Filer Rebill functionality.
Submit a Replacement claim through standard Pro-Filer Rebill
functionality.
See the Corrected, Replacement & Voided Claims Procedures End User Guide for
For EXCLUDED Remit Services, these can be easily identified through the Electronic
Remittance Batch Report.
Run the Electronic Remittance Batch Report for Excluded Records Only and
searching on $0.00 to review all zero payment remit records and their reported COB
information.
reasons by running for Yes to Show Service Level Adjustments and Show
Service Level Amounts.
Page 50
Remittance
Electronic
Billing Guide
Research each service for which a zero payment was received through the Review
Accounts form and the Clients record.
Take appropriate actions depending on the specific denial and Client information.
See the Corrected, Replacement & Voided Claims Procedures End User Guide for
STEP 9: RECONCILLIATION
Reconcile and report transaction applications and associated stored COB data and validate
that both the Payment record Unapplied Balance and all associated Billing Line balances (for
this Payor) have been reduced to zero by using the following reports.
Run the Payment Application Individual Report for Detail and Yes to Show Billing
Line COB Data:
1. Verify that all Payment record identification fields were entered correctly.
Check Date, Deposit date, Description, Deposit Number, etc.
Make corrections as necessary.
2. Verify that the Unapplied Balance has been reduced to ZERO (either through Payment
Application or through Payment Entry Adjustments).
Run the Electronic Remittance Application Report for Billing Line Revenue Balance <>
Zero and Remit Recorded Service (Billing Line):
3. Verify that ALL Billing Lines reported are reduced to ZERO (i.e. no records returned),
except in denial cases were the Billing Line is already marked for Rebill in Step #8.
4. If any corrections were needed, re-run the report and verify as above.
5. Save the final reconciled reports on-line for future reference, as needed.
Hint: The Payment Application Report can also be run in Excel export format, if this is
preferred for reconciliation and/or documentation purposes.
Page 51
Remittance
Electronic
Billing Guide
Page 52
Remittance
Electronic
Billing Guide
ELECTRONIC REMITTANCE REPORTS

Electronic Remittance Application Report
Report the resulting transaction applications by using the Electronic Remittance Application
Report.
This report can also be used to identify any matched Revenue Lines that still carry a balance
(whenever Transfer the Balance functionality is not used); to review COB data stored during
the application process (includes CAS, AMT & LQ segments); to review Adjustment and
Transfer Amounts and Types, as well as the Payors the Transfers were moved to.
Payment Application Individual Payment Report
The Payment Application Individual Payment Report can also be used to report the resulting
transaction applications and to verify all transactions have been applied fully and correctly,
especially after any further necessary manual application has been completed.
This report has predefined sorting levels by Client and Claim. Totals of payments, adjustment
and transfers are given for each level. A running total of applied and unapplied payment
entries are given for each payment record. The report can be created for detail or summary
and can be exported in an Excel format.
Electronic Remittance Batch Report
This report is generated from the Pro-Filer REMIT tables, which are populated from an
incoming electronic remittance file to create the Electronic Remittance Batch record.
After the incoming electronic remittance file is parsed into Pro-Filer, this report may be run on
the ERemit batch during ANY stage of its processing to show details of the adjudicated
services, the status of these services (Matched, Excluded and/or Applied), the reported charge
and payment amounts, and the COB Data as it was received in the incoming file, whether it is
defined to be applied to the Pro-Filer Revenue Lines or not.
ERemit Batch Information
This report provides summary information across Electronic Remittance batches.
ERemit Batches may be selected for reporting by date range and a parameter allows record
selection by Payment Received Date, Check/Remit Date or Remit Production Date. Records
may also be returned for one Payor, multiple Payors or all Payors.
Electronic EOB Report
This report will pull information from the Pro-FilerTM Remit Tables to generate the Electronic
EOB Report. This provides the explanation of benefits for remittances processed through the
electronic remittance process.
Page 53
Remittance
Electronic
Billing Guide
Important Note: Please review the instruction documents for each of these reports for
full usage information. The instruction documents for every report can be found in the
downloaded .zip file that also contains the actual .rpt Crystal Report file.
Page 54
Remittance
Electronic
Billing Guide
DELETING PENDING ELECTRONIC

REMITTANCE BATCHES
Only Pending Electronic Remittance batches should be deleted.
Find the Pending batch to be deleted, right click and choose delete:
Say Yes to the presented message box:
Follow the same Delete process for the Payment Entry record that was created with the
deleted ERemit batch:
Important Notes:
Page 55
Remittance
Electronic
Billing Guide
Logged in users who have Administrative Override privileges CAN delete Complete
ERemit Batches. (This does NOT delete the applied transactions of its associated
payment record.)
This function should ONLY be implemented for database purging purposes (i.e. after
ALL ERemit information has been stored and documented elsewhere and NO more
reporting from the individual ERemit Batch is needed).
CoCentrix recommends keeping the ERemit Batch records for a minimum of 2 to 3
years.
Page 56
Remittance
Electronic
Billing Guide
TROUBLE SHOOTING
MANUALLY MATCHING AN AUTO -MATCHED SERVICE
A matched service can be manually re-matched by highlighting the Remit Service and
selecting the UnMatch Service button:
(To re-match, follow the manual matching process outlined in the ERemit guide.)
CORRECTING COMPLETE EREMIT BATCHES

Generally speaking, applied transactions from an ERemit process can only be corrected
mamually by accessing the Payment record used to apply the transactions initially and then
applying reversing amounts from the same record.
However, is some situations you may contact the CoCENTRIX ServiceDesk to assist you in
determining what condition your ERemit Batch and Payment record are in and what possible
corrective actions can be taken.
Page 57
Remittance
Electronic
Billing Guide
ADJUSTMENT TYPE CROSSREFERENCES

Examples Only:
X-Ref on
835
Adjustme
nt
Description
Adjustme
nt
Adjust Pro-Filer
?
Code
Type?
CAS
Reason
Codes
Adjustme
nt Type
Code
15
Auth # Missing, Invalid,
No
01
No
16
Lacks Information for

Adjudication
No
02
No
22
Covered by Another Payer

per COB
No
03
No
38
Services Not Authorized
Yes
04
Yes
47
Diagnosis Not Covered,

Missing, Invalid
No
05
No
150
Doc Does Not Support this

Level of Care
No
06
No
35 & 119 Benefit Maximum Reached Yes
07
Yes
129
Prior Processing Information Yes

Incorrect
08
Yes
133
Claim Pending Further

Review
No
09
No
141
Claim Spans
Eligible/Ineligible Periods
No
10
No
18
Duplicate Claim/Service
Yes
11
Yes
Page 58
Remittance
Electronic
Billing Guide
23
Charges Paid by Another

Payor
No
12
No
45
Charges Exceed Fee

Schedule
Yes
13
Yes
A1
Denied Charges
No
14
No
Build a Cross Reference Type called 835 Adjustments (or similar).
Note: Claim Adjustment Reason Codes can be found on the Washington Publishing
Companys website at: http://www.wpc-edi.com/codes/claimadjustment
In this example, all of the Pro-Filer Adjustment Type records indicated with a Yes in the XRef on Adjustment Type column above will have a Cross-Reference record built using the
Cross Reference Type 835 Adjustments.
When any of these CAS Reason Codes are encountered, the program will automatically apply
an adjustment transaction equal to the value reported and using the Pro-Filer Adjustment Type
in which that code is entered in the Cross References Code field.
Each of these Cross-Reference records will be built with the value indicated in the CAS Reason
Codes column in the Code field and will be built using the appropriate Cross Reference
Type (i.e. - 835 Adjustments). Example:
Page 59
Remittance
Electronic
Billing Guide
When the 835 remittance file is parsed into Pro-Filer, the parsing tool will evaluate the 835
Adjustments Cross Reference Type records against the incoming Claim Adjustment (CAS)
Reason Codes contained in the CAS segments of the file.
If an Adjustment Type record Cross Reference exists for the CAS Reason Code found in the file,
the ERemit program will apply the adjustment transaction (amount and adjustment type),
along with the payment, to matched services.
If a Cross Reference record does not exist for the CAS Reason Code found in the file, the
ERemit program will not apply the adjustment transaction.
Important: If the Electronic Remittance program is being implemented for multiple

Payors (for the 835 format) and they DO NOT share the same adjustment definitions for
the same Claim Adjustment Reason Code, multiple Adjustment Cross-Reference
Types, based on Pro-Filer Payors, should be developed.
For Example, if the agency decides that Medicaid Claim Adjustment Reason Code 38
(Services Not Authorized) CAS Amounts should be adjusted off for Medicaid, but not for
BCBS, then at least two different Adjustment Cross-Reference Type records should be
used (i.e. Medicaid 835 Adjustments and BCBS 835 Adjustments).
Page 60
Remittance
Electronic
Billing Guide
TRANSFER TYPE CROSS-REFERENCES

Examples Only:
835
Patient
Responsibilit
y
Description
X-Ref on
Pro-Filer
Transfer? Code
CAS
Reason
Codes
Transfer
Type
Transfer
Type Code
Deductible
Yes
01
Yes
Coinsurance Amount
Yes
02
Yes
Co-payment Amount
Yes
03
Yes
26
Expenses incurred prior

to coverage
Yes
04
Yes
27
Expenses incurred after

coverage terminated
Yes
05
Yes
33
Insured has no
dependent coverage
Yes
06
Yes
100
Payment made to
Yes
patient/insured/responsib
le party/employer
07
Yes
119
Benefit maximum for this Yes

time period or
occurrence has been
reached
08
Yes
122
Psychiatric reduction
Yes
09
Yes
142
Monthly Medicaid patient Yes

liability amount
10
Yes
178
Patient has not met the

required spend down
11
Yes
Page 61
Remittance
Yes
Electronic
Billing Guide
requirements
179
Patient has not met the

required waiting
requirements
Yes
12
Yes
Build a Cross Reference Type called 835 Transfers (or similar).
Note: Claim Adjustment Reason Codes can be found on the Washington Publishing
Companys website at: http://www.wpc-edi.com/codes/claimadjustment
In this example, all of the Pro-Filer Transfer Type records indicated with a Yes in the X-Ref
on Transfer Type column above will have a Cross-Reference record built using the Cross
Reference Type 835 Transfers.
When any of these CAS Reason Codes are encountered (in conjunction with a CAS Group
Code of PR), the program will automatically apply a Transfer transaction (to the next Payor)
equal to the value reported and using the Pro-Filer Transfer Type in which that code is entered
in the Cross References Code field.
Build a Cross Reference Type called 835 Adjustments (or similar).
Each of these Cross-Reference records will be built with the value indicated in the CAS Reason
Codes column in the Code field and will be built using the appropriate Cross Reference
Type (i.e. - 835 Transfers).
Example:
Page 62
Remittance
Electronic
Billing Guide
When the 835 remittance file is parsed into Pro-Filer, the parsing tool will evaluate the 835
Transfers Cross Reference Type records against the incoming Claim Adjustment (CAS) Reason
Codes contained in the CAS segments of the file.
If a Transfer Type record Cross Reference exists for the CAS Reason Code found in the file, the
ERemit program will apply the transfer transaction (amount and transfer type), along with the
payment, to matched services.
If a Cross Reference record does not exist for the CAS Reason Code found in the file, the
ERemit program will not apply the transfer transaction.
Important Note: If the Electronic Remittance program is being implemented for

multiple Payors (for the 835 format) and they DO NOT share the same transfer
definitions for the same Claim Adjustment Reason Code, multiple Transfer CrossReference Types, based on Pro-Filer Payor, should be developed.
For Example, if the agency decides that Medicaid Claim Adjustment Reason Code 122
(Psych Reduction) CAS Amounts should not be transferred to Self-Pay for Medicaid, but
should be transferred when reported from BCBS, then at least two different Transfer
Cross-Reference Type records should be used (i.e. Medicaid 835 Transfers and
BCBS 835 Transfers).
COB DATA STORAGE

COB DATA IN THE EREMIT BATCH
Double click on any row within the Services from electronic Remittance section:
The COB Data is displayed within the Service manual matching forms Service Adjustments
list box:
Page 63
Remittance
Electronic
Billing Guide
Rows with NO Adjustment Group Code are populated from AMT segments within the
incoming 835 Remittance file:
Some common examples of AMT information are Allowed Amount (B6); Per Day Limit (DY);
Deduction Amount or Late Filing Reduction (KH).
AMT data is informational only, in that it does NOT generate either Adjustments or transfers
during the ERemit process. AMT data is stored because it is often required information in
subsequent Payor claims (secondary, tertiary, etc.).
Rows WITH an Adjustment Group Code are populated from CAS segments within the
incoming 835 Remittance file:
Page 64
Remittance
Electronic
Billing Guide
Possible CAS Adjustment Group Codes include:

CO:
Contractual Obligations
PR:
Patient Responsibility
OA:
Other Adjustments
PI:
Payor Initiated Reductions
CAS data DOES generate both Adjustments and/or Transfers during the ERemit process,
depending on user-defined Cross References. CAS data is also stored because it is required
information in subsequent Payor claims (secondary, tertiary, etc.).
COB DATA IS STORED AT THE BILLING LINE LEVEL

ALL COB Data (AMT & CAS segments) returned in the 835 remittance file is stored in Pro-Filer
(upon the ERemit Apply process) at the Billing Line level.
To review and/or add COB Data, go to the Review Accounts form and filter for the Show =
Claim/Billing Line option:
Highlight the desired Billing Line from the Results tab and select the COB Data button:
Page 65
Remittance
Electronic
Billing Guide
The COB Data form should display the same AMT & CAS segment information as was observed
and stored in the ERemit Batch:
AMT & CAS Data can be entered manually by accessing the New Form icon from this form.
It is from this form that the AMT & CAS COB Data will be pulled (by the non-primarys Billing
form Layout) to report this information in subsequent Payor claims.
See the COB Storage & Reporting in Electronic Claims End User Guide for additional
information.
COB DATA IN EREMIT REPORTS

COB Data in the Electronic Remittance Batch Report:
COB Data in the Electronic Remittance Application Report:
COB Data in the Payment Application Individual Payment Report:
Page 66
Remittance
Electronic
Billing Guide
COB Data in the Electronic EOB Report:
Page 67
Remittance
Electronic
Billing Guide

835 Billing..Electronic Remittance Guide

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

835 Billing..Electronic Remittance Guide

Transféré par

Droits d'auteur :

Formats disponibles

Billing Guide

HIPAA Electronic Remittance

STEP 2: Auto match Processing............................................................24

STEP 4: Manually Matching NO Services...............................................32

STEP 5: Toggle Exclud Non-Matched Services........................................37

Step 8: Work Zero Payments (Denials)......................................................43

COB Data Storage.................................................................................... 55

EREMIT PROCESSING CHOICES:

DEFINITIONS OF APPLIED TRANSACTIONS:

DEFINITIONS OF OTHER STORED

CAS data is returned in Groups (categories) of adjustments. These categories help

7. Manually correct, apply or refund any remaining non-processed transactions contained

PARSING THE REMITTANCE FILE

REMIT PARSE ENGINE CONNECTION: (ONE TIME

Must be installed on the Pro-Filer Client machine

5. Select Import to Pro-Filer:

Auto Apply Adjustments: Check this box to activate this functionality.

Auto Apply Transfers: Check this box to activate this functionality.

Note: ONLY check the Adjustments and/or Transfers checkboxes if automatic

Amount: Total monetary amount for all claims/services in this batch.

Remit Payor Section:

Payor: This is the Pro-Filer Payor chosen during parsing. (Required)

Example of Show Services for Selected Claim:

STEP 2: AUTO MATCH PROCESSING

Example of matched services:

Example of non-matched service:

STEP 3: MANUAL MATCHING YES? SERVICES

YES VS. YES? IN EREMIT AUTOMATED MATCHING

STEP 4: MANUALLY MATCHING NO SERVICES

POSSIBLE REASONS FOR NON-M ATCHED SERVICES:

Pro-Filer Service was Voided/Reclassed after original billing.

RESEARCHING NON-MATCHED SERVICES:

Use the Review AR form to review the Pro-Filer posted service:

**Billed Payor; Client ID and Date of Service

Very Important Notes:

STEP 5: TOGGLE EXCLUDE NON-MATCHED

STEP 6: AUTO APPLY & S AVE

The Claims tab Remit Services Totals information will be updated:

STEP 7: MANUAL CORRECTIONS/APPLICATIONS

WORKING EXCLUDED REMIT SERVICES

WORKING NON-ZERO BAL ANCE REVENUE LINES

Manually apply any appropriate remaining Adjustments that were not

REPORTING NON-ZERO BALANCE HINTS for the Electronic Remittance Application

STEP 8: WORK ZERO PAYMENTS (DENIALS)

ELECTRONIC REMITTANCE REPORTS

DELETING PENDING ELECTRONIC

Say Yes to the presented message box:

CORRECTING COMPLETE EREMIT BATCHES

ADJUSTMENT TYPE CROSSREFERENCES

Auth # Missing, Invalid,

Lacks Information for

Covered by Another Payer

Services Not Authorized

Diagnosis Not Covered,

Doc Does Not Support this

35 & 119 Benefit Maximum Reached Yes

Prior Processing Information Yes

Claim Pending Further

Charges Paid by Another

Charges Exceed Fee

Build a Cross Reference Type called 835 Adjustments (or similar).

Important: If the Electronic Remittance program is being implemented for multiple

TRANSFER TYPE CROSS-REFERENCES

Expenses incurred prior