835 Billing..Electronic Remittance Guide

Billing Guide

CoCentrix, INC.PRO-FILER™HIPAA Electronic Remittance (835) ImportHIPAA File ImportsUpdated: 5/1/2015

TABLE OF CONTENTSTable of Contents.......................................................................................1General Information...................................................................................3ERemit Components:..................................................................................3ERemit Processing Choices:........................................................................3Definitions of ‘Applied’ Transactions:..........................................................3Definitions of Other ‘Stored’ EOB/Remittance Advice Data:..........................4Installation Instructions..............................................................................5Processing Steps........................................................................................6STEP 1: Parsing the Reittance File.............................................................8

Remit “Parse Engine” Connection: (One Time Process)...........................................................8Creating the Remit Batch: (Parsing the Remittance File).........................................................9

Electronic Remittance Batch Form......................................................................................14Remit Batch Tab................................................................................................................. 15Claims Tab.......................................................................................................................... 21

STEP 2: Auto “match” Processing.............................................................24STEP 3: Manual Matching “YES?” Services.................................................27

“YES” vs. “YES?” in ERemit Automated Matching..................................................................31STEP 4: Manually Matching “NO” Services................................................32

Possible Reasons for Non-Matched Services:.........................................................................32Researching Non-Matched Services:......................................................................................32

STEP 5: “Toggle Exclud” Non-Matched Services........................................37STEP 6: Auto “Apply” & “Save”................................................................38Step 7: Manual CorrectionS/Applications...................................................41

Working “Excluded” Remit Services......................................................................................41Working Non-Zero Balance Revenue Lines............................................................................41

Step 8: Work Zero Payments (Denials)......................................................43Step 9: Reconcilliation..............................................................................44Electronic Remittance Reports..................................................................45Deleting Pending Electronic Remittance Batches.......................................46

Page 1 Electronic Remittance

Release Date: 1/1/2013 Billing Guide

Trouble Shooting......................................................................................48Manually Matching an Auto-Matched Service.............................................48Correcting “Complete” ERemit Batches.....................................................48Adjustment Type Cross-References...........................................................49Transfer Type Cross-References................................................................52COB Data Storage.....................................................................................55COB Data in the ERemit Batch...................................................................55COB Data is Stored at the Billing Line Level...............................................56COB Data in ERemit Reports......................................................................57



GENERAL INFORMATIONThis guide is intended to explain Pro-FilerTM Classic’s Electronic Remittance (ERemit) functionality; the process of parsing an 835 Electronic Remittance file into Pro-FilerTM 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. HipaaParseSetup.zip file 2. HIPAA Parse Scripts (as needed)3. Electronic Remittance Batch Report (.zip file)4. Electronic Remittance Application Report (.zip file with .sql script)5. ERemit Batch Information Report (.zip file with .sql script)6. Electronic EOB Report (.zip file with .sql script)7. Electronic Remittance Find Queries (.doc file)8. 5010 837 Active Report for Secondary Electronic Claims after Electronic Remittance

processing

EREMIT PROCESSING CHOICES: 1. Payments Only2. Payments and Adjustments Only (Adjustments are user defined.)3. Payments and Transfers Only (Transfers are user defined.)4. Payments, user defined Adjustments and user defined Transfers5. 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



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’.



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.



INSTALLATION INSTRUCTIONS1. 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 staff.) 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



8. Develop a plan to re-index / defrag / shrink and update the SQL statistics of your Pro-FilerTM database by reviewing the information provided in Knowledgebase Article KBA-01341 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.



https://servicedesk.cocentrix.com/KnowledgeBase

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



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 Medicare’s “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.



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 machineConnect 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 Pro-Filer™ tree, but is recommended at the Billing & AR/Electronic Remittances folder level.



CREATING THE REMIT BATCH: (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’.

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”:

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”:

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.



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 Pro-Filer 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-FilerTM reconciliation and transaction reports also use the “Date Received” field for accurate reporting.



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 agency’s 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”:



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:

ELECTRONIC REMITTANCE BATCH FORMGo to: Billing & AR/Electronic Remittances folder. Open the Electronic Remittance Batch to be processed (use the ‘Find’ feature when necessary):



Electronic Remittance


REMIT BATCH TAB

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.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.



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.



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.)



“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.



CLAIMS TABThe 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.



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.



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 Pro-Filer™ 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.



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).



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 program’s process:



The Claims tab information will be updated when the matching process is complete:

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 1st & 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.



Example of matched services:

Example of non-matched service:



STEP 3: MANUAL MATCHING “YES?” SERVICESSort 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 Pro-Filer™ 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:



Select the “Find” button to display the Revenue Line matching possibilities.



Highlight the correct Pro-Filer™ record and select the “Match Service” button.



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.



“YES” VS. “YES?” IN EREMIT AUTOMATED MATCHINGRemit 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

modifiers2. 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 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 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



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-MATCHED 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 Line’s present condition.

Example:Service was voidedNon-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.



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 billedNon-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:



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: **Billed Payor; Client ID and Date of ServiceHowever, 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 service’s 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:



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.



Always “SAVE” all the ERemit Batch changes before proceeding to the “Apply” process.



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:



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” & “SAVE” 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 program’s process:



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:



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.



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 SERVICESManually 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 re-posted 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 BALANCE REVENUE LINESThe 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 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.

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 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 form’s services grid can be sorted to follow the printed report generated in Step 1 or the Excel output from Step 3.



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.

This report will also display the CAS & LQ codes returned that define the denial reasons (CARC) and additional remark codes (RARC).

Research each service for which a zero payment was received through the Review Accounts form and the Client’s 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 additional information.

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.

This report will also display the CAS & LQ codes returned that define the denial reasons by running for “Yes” to “Show Service Level Adjustments” and “Show Service Level Amounts”.

Research each service for which a zero payment was received through the Review Accounts form and the Client’s record.



Take appropriate actions depending on the specific denial and Client information.

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 still equal ZERO.See the ‘Corrected, ‘Replacement’ & ‘Voided’ Claims Procedures’ End User Guide for

additional information.

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’).

Make corrections as necessary.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.

Make corrections as necessary.

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.




ELECTRONIC REMITTANCE REPORTSElectronic Remittance Application ReportReport 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 ReportThe 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 ReportThis 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 InformationThis 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 ReportThis 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.



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.



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:



Logged in users who have “Administrative Override” privileges CAN delete ‘Complete’ ERemit Batches. (This does NOT delete the applied transactions of it’s 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.



TROUBLE SHOOTING MANUALLY MATCHING AN AUTO-MATCHED SERVICEA 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 BATCHESGenerally 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.



ADJUSTMENT TYPE CROSS-REFERENCES Examples Only:

835 Adjustment Description

Adjust?

Pro-Filer™ Code

X-Ref onAdjustmentType?

CAS Reason Codes

Adjustment 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 Incorrect

Yes 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

23 Charges Paid by Another No 12 No



Payor

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

Company’s website at: http://www.wpc-edi.com/codes/claimadjustmentIn this example, all of the Pro-Filer™ Adjustment Type records indicated with a ‘Yes’ in the “X-Ref 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 Reference’s ‘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:



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”).



TRANSFER TYPE CROSS-REFERENCES Examples Only:

835Patient Responsibility Description Transfer?

Pro-Filer™ Code

X-Ref onTransferType

CAS Reason Codes

Transfer Type Code

1 Deductible Yes 01 Yes

2 Coinsurance Amount Yes 02 Yes

3 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 patient/insured/responsible party/employer

Yes 07 Yes

119 Benefit maximum for this time period or occurrence has been reached

Yes 08 Yes

122 Psychiatric reduction Yes 09 Yes

142 Monthly Medicaid patient liability amount

Yes 10 Yes

178 Patient has not met the required spend down requirements

Yes 11 Yes



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

Company’s website at: http://www.wpc-edi.com/codes/claimadjustmentIn 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 Reference’s ‘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:



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 ‘Cross-Reference 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 form’s “Service Adjustments” list box:



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:

Possible CAS “Adjustment Group Codes” include:CO: Contractual ObligationsPR: Patient ResponsibilityOA: Other AdjustmentsPI: 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 LEVELALL 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:

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-primary’s 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 REPORTSCOB Data in the Electronic Remittance Batch Report:



COB Data in the Electronic Remittance Application Report:

COB Data in the Payment Application – Individual Payment Report:

COB Data in the Electronic EOB Report:



835 Billing..Electronic Remittance Guide

Documents

Transcript of 835 Billing..Electronic Remittance Guide