Chapter 26 Financial Procedures

Report as inappropriate Your report has been received

Shared by: HC120916133156

Tags

Stats

views:: 0
posted:: 9/16/2012
language:: English
pages:: 10

Public Domain

Document Sample

Chapter 26 Financial Procedures

26.0 Updating FFP Rates
Before the first weekly cycle in October, the state should send a numbered memo
requesting us to updating the FFP rates for the upcoming fiscal year (the State’s federal
fiscal year starts in October). Update the following sysin member –
NEWM.PROD.SYSIN(FW2000DC). Remove the entries for the oldest year to make
room for the new years’ entries. Copy the rows from the previous fiscal year and make
the appropriate changes for the new fiscal year.

26.1 Adding a new Account Code
Update copybook AIGLTBL and recompile NMMF2000. Look at project 231305 as an
example.

If the account code that you’re adding is a cash account (starts with 002-80-xxx), then
you’ll need to update NMMC5000 and NMMF2060 as well. This is so the reports will
show we’re in balance. See changes for PL6202 as an example.

Add the new account code to the Financial subsystem chapter of the system
documentation. See exhibit 15D-5exhb. This exhibit lists all account codes and FFP
rates.

26.2 Adding a new Cost Center
1. Add the new cost center to the C-COST-CENTER-CD valid value list in OmniAdd.
The copybooks that get updated are WVC7827C and WVC7827D.

2. Update the appropriate cost center copybook.
a. If the claim COE/FM data will be used to determine cost center, then update
WHC45151.
b. If the new cost center will be assigned to waiver claims, then update WHC45154.
c. Some cost centers are not stored in a copybook/sysin member. Instead, they are
assigned in program NMSC4515. See step #4 for more details on adding these
types of cost centers.

Financial Procedures March 25, 2009 26-1
3. After updating the appropriate copybook, update its corresponding sysin member.
The copybooks and sysin members must remain in sync. Apply the updates
according to the table below:

If you update Cost Center copybook Also update Cost Center sysin
WHC45151 AIF13

4. If the new cost center will not be stored in one of the 3 copybooks/sysins, then add
the logic for assigning the new cost center to program NMSC4515. See changes
marked PL6274 in section S200-EXCP-ASSIGN for an example.

5. Update NMMF1000 only if the new cost center can be reported as an alternate cost
center on the Claim Accounting Transaction File.

6. Recompile NMSC4515. It may also be necessary to recompile and newcopy program
NMDC8720 to pick up the change to NMSC4515.

7. Recompile any programs that use the C-COST-CENTER-CD copybooks WVC7827C
and WVC7827D.

8. Update sysin FW2000DB with the new cost center and the related account code
information provided by the State.

9. Update sysin FW2000DC with the new cost center and the related FFP rate
information provided by the State.

10. System documentation update – add the new cost center to the Cost Center
Assignment exhibit in chapter 11D-5exhb.

26.3 Troubleshooting Financial Out-of-Balance
Once you’ve identified the TCN’s, you will need to notify ASD so they can make the
corrections on their side. (Note: If the purpose of the history only adjustment was so
money could be identified under a different cost center, then you will need to figure out
how to resolve the situation. You won’t be able to use the methods described in this
document to send the corrections to ASD. This has never happened before, but you need
to be aware of this. The reason you can’t use the methods described below is because we
basically back out the history only adjustment. For the most part, ASD doesn’t need to
have history only adjustments reported to them. The main reason they would need to
have them is for cases where we’re changing something like the cost center.)

NEWM.PROD.PDS.EZ(FINPROV) – This eztrieve can be used to identify the provider
that is causing the out-of-balance conditions. Look at Rpt1 – Rpt4 out of step100. Once
you have the provider(s) that are causing the out of balance, you can use
NEWM.PROD.PDS.EZ(FINPROV2) to identify all their history only claims (99% of the

Financial Procedures March 25, 2009 26-2
time we’re out of balance because of something to do with history only claims.) You’ll
need to modify this eztrieve by updating the provider ID in question. By looking at the
TCN’s out of the second eztrieve, you can try to determine what’s happening by looking
at the scenarios described below. These scenarios have happened in the past at one time
or another.

Other eztrieves that have been developed are listed below. They were useful at one time
to identify specific issues, but most likely won’t help too much in the future. They are
listed here for information purposes.

1. In the most recent OOB situation on 3/20/09, eztrieve
NEWM.PROD.PDS.EZ(OOBHISTO) was used to find the claims causing the
OOB. This ez simply lists the history only system generated claims in
PRNTOUT1, as these seem to be causing the most recent issues. The eztrieve also
summarizes all of the claims on the weekly file by C-BAT-MED-SRC-CD, C-
BAT-PYMT-TY-CD, and C-HDR-TXN-TY-CD, which may also be helpful. The
eztrieve NEWM.PROD.PDS.EZ(FINCLBAL) has been helpful in the past. This
eztrieve compares the zero generation of NEWM.PROD.C4560SA.DATA to the
zero generation of NEWM.PROD.F1000SA.DATA to see if there are any
differences in the payment amounts between claims and financial records for the
same TCN. This should identify problems where claims were included in one
subsystem and not the other. This has been very helpful in identifying claims
where the debit has been deleted, but the credit still goes through claims. Reports
RPT2 – RPT4 out of STEP140 will be the most helpful.
2. Look at report RF003 – State Institution Summary
(NEWM.PROD.F2040RA.LIST(0)) to see if there are any ‘State’ providers.
There should not be any providers listed on this report – if there is, we will be out
of balance by the total amount of claims for the provider. This was happening
towards the beginning of Omnicaid implementation. This should not really
happen anymore since the State has not identified any providers to be ‘State’
providers. If this does happen, you need to send an email to Sal Montano and let
him know – the provider might have been added incorrectly.
3. NEWM.PROD.PDS.EZ(HISTADJ) – this will identify the history only
adjustments that weren’t entered with an FCN and the debits and credits have
different reimbursement amounts. For the most part, every history only
adjustment will have an FCN (merge and unmerge are excluded). The
reimbursement amounts have to be the same in order to be in balance since claims
does not count history only records. PRNTOUT1 in Step060 will identify the
TCN’s and their amounts. Subtract the debit tally from the credit tally, and this
should give you the total difference.
4. NEWM.PROD.PDS.EZ(FINADJ) – rpt3 out of step140 will identify claims that
were entered with the wrong FCN. The very last step will identify the
adjustments that don’t have a correct offsetting financial claim. (Note: This
eztrieve has not been modified for HIPAA yet, so it won’t work until changes are
made.)

Financial Procedures March 25, 2009 26-3
Here are some of the situations that have caused out-of-balance conditions and the
actions that were taken to resolve them.

1. Credit claims without a debit. This has happened because someone has worked a
suspended claim to a ‘to-be-paid’ or ‘to-be-denied’ status. However, they choose
the claim again and end up deleting it. Once a claim is in it’s final status, the
credit is created. When they delete it, it only deletes the debit side. Financial
always assumes that a credit will have a debit and will bypass either one if they’re
not both there. Therefore, causing financial to be out of balance to claims.
PL3872 was created to fix this problem. However, because of the difficulty
changing it online, it was decided to wait for HIPAA to make the changes. Until
these changes are made, here are the steps to go about resolving the issue.
a. Identify who created the problem by pulling the TCN off of the image
copy done by the DBA’s. (Instructions on how to do this are later in this
document.) Once you’ve identified the person, you need to call them
and make sure they know not to do this again.
b. Email the credit claim to John Mauk and the NM Business Analysts and
tell her that we have another situation where the credit went through
claims without the debit. She should know what to do, but tell her she
needs to enter a new corrected claim to offset the credit and add an EOB
to tell the provider what happened.
c. At the end of the month, the credit claim needs to be accounted for on
the file that we send to ASD. Any out of balance condition that happens
during the month needs to be reported to ASD so they can correct their
books. Instructions on how to do this will be provided later in this
document.

2. User tries to delete a receipt, but the online does not delete the financial claim that
was created. When a user enters a receipt through the receipt window in
financial, the online windows creates a financial claim to record the receipt. If
they realize they entered an incorrect reason code for the receipt, and it’s before a
payment cycle, they can delete the receipt by changing the amount and warrant to
zero. This should work fine, however, the online window does not delete the
financial claim that was created. Since it’s a history only claim, it goes through
financial and not through claims, causing us to be out of balance. PL4376 was
created to fix this online problem. Until this was fixed, though, Dennis Leasure
(now Sal Montano) was notified of the problem and was instructed to tell the
financial department that when they notice they’ve made a mistake and try to
delete the receipt, they need to call someone on the maintenance team to run a
spufi to delete the TCN from the claims tables. At the end of the month, these
transactions need to be included in the adjustments that are sent to ASD.

3. Pay to provider claims to the dummy provider ID (99999998). The claims
subsystem does not create checks to a dummy provider. However, there have
been some instances of pay-to-provider claims with this billing provider ID.
Since Claims does not create checks for these providers, they would not be

Financial Procedures March 25, 2009 26-4
included in the payment file. However, the claim does go through to financial and
is reported on. This occurred more in the beginning of when Omnicaid went live,
and would most likely not happen again. However, you should be aware.

4. History only originals. There is not any reason that someone should enter a
history only original claim. Adjustments and voids should be the only ones that
are history only. PL4259 was created to prevent users from entering history only
originals. This should not happen again.

5. TPL adjustments. When Omnicaid was first implemented, ASD discovered that
their numbers were out of balance each month. We discovered that Omnicaid was
treating TPL adjustments differently than the old system. The old system never
created history only adjustments when users entered receipts from billing records.
The financial claims go to a different account code than the adjustments. One
goes to the cash account and the other goes to a TPL revenue account. Since
they’re in different accounts, they don’t balance each other out causing us to be
out of balance with ASD. So, a change was made so that history only adjustments
for TPL are not sent to ASD (adjustment reason codes 046 and 047). This was
done with project 221405.

6. Financial claim doesn’t offset the debit and credit. The net affect of the debit and
credit should equal the total amount on the financial claim. If they set up a receipt
for say $100 and they adjust a claim to go against that receipt, if the net affect of
the debit and credit is < 0, it creates an offsetting claim with $0 reimbursement
amount. This causes us to be out of balance.

7. History only claims pricing differently. History only adjustments should not price
differently. The only history only adjustments that would price differently are for
TPL (because TPL would be taken out of the reimbursement). A change was
made under project 221610 to prevent this from happening. This should not
happen in the future.

8. User enters a batch of history only adjustments, but enters a wrong adjustment
reason for one of the claims. They don’t enter an FCN for it, and it ends up
pricing differently because they enter a TPL amount. This causes the debit claim
to price differently from the credit claim. Since they didn’t enter an FCN, the
financial claim doesn’t offset the difference. This causes us to be out of balance.

See the G:\NEWM\TRAINING MATERIAL\Financial Out of Balance L&L for a
PowerPoint presentation of out of balance troubleshooting.

Financial Procedures March 25, 2009 26-5
26.4 Sending out of balance detail to ASD
The job NMCW5000 identifies when the financial and claim subsystems are out of balance. When this happens, it’s necessary to send
some information to ASD (Accounting Services Division). The reason we need to do this is because they receive a monthly file from
us with financial information. They know when we’re out of balance and they need to adjust their books when any out-of-balance
condition occurs.

Every time we have been out of balance it has been because of history only transactions.

The following is instructions on what to do when you’re out of balance and you need to send the information to ASD.

1. See G:\NEWM\FINANCIAL\ASD BALANCING DETAILS. You’ll see all the documents we’ve sent to ASD. Copy one of
them as an example and change the month.

2. Find the TCN that caused the out of balance for that month. Note: If the TCN that caused the out of balance is a debit or
credit, you need to extract both of them. NMFW1000 is expecting the pair together.

3. Using file-aid, extract the TCN off the generation file out of NMCW4560 (NEWM.PROD.C4560SA.DATA.ADJCLMS). Copy
the TCN to NEWM.TEST.C4560SA.DATA.ADJCLMS.EXT.

4. Use JCL in NEWM.PROD.PDS.JCL(NMFW1000) to run the TCN through NMMF1000.

5. Run NEWM.PROD.PDS.JCL(NMFW2000) using the output from NMFW1000. After it runs, look at the report
NMDV.TEST.F2000RA.LIST(0) and copy the information from the last page into the excel spreadsheet. Usually the out of
balance is because we included a claim that shouldn’t have been included. So, you need to reverse the sign of the amounts (i.e.
If it was positive make it negative). This will tell ASD they need to reverse what was sent to them for this claim. You’ll need
to make sure you understand why we were out of balance to know whether you need to reverse the signs or not. There might
be instances in the future where we originally bypassed the claim. In this instance, we wouldn’t want to reverse the signs.

6. Run NEWM.PROD.PDS.JCL(NMFM4090). This is run just to create a file that will go into the next step.

Financial Procedures March 25, 2009 26-6
7. Run NEWM.PROD.PDS.EZ(ASDFILE). This eztrieve was made to identify the fiscal years each accounting code/cost center
went into. You’ll need to enter the amounts on the spreadsheet under the appropriate fiscal years.

8. Once you’ve created the document, you can double-check to make sure what you’re sending is accurate. See the below as an
example.

Cost Center Debit Credit
86704 $0.00 $690.00
002-80-005 (690.00) 0
026-80-001 $0.00 $512.67
078-80-018 (512.67) 0

The first two accounts in this table need to add up to zero. The first is the cost center assigned to the claim and the second is
what’s called the ‘cash account’. The last two also need to add up to zero. These are the FFP accounts. These are the
accounts that show the FFP (federal financial percentage) applied to the claim. Of course there are more accounting codes
than these, but make sure the cost center and cash account add up to zero.

9. Send the file to carolee.graham@state.nm.us.

Financial Procedures March 25, 2009 26-7
FIGURE 3 - FINANCIAL ACCOUNTING DECISION
TABLE
T 9 A C S DEBIT CREDIT FEDERAL
TRANSACTION TYPE P 9 R S P TXN DESCRIPTION ACCOUNT ACCOUNT ACCOUNTS

REFUND TRANSACTIONS
Level I, Method 06 - Provider Refund Receipts 2 - + 020 Cost Settlement N/A N/A N/A
021 Fraud and Abuse N/A N/A N/A
022 Federal /State Audit Findings N/A N/A N/A
023 Provider Refund - Overpayment N/A N/A N/A
024 TPL Provider Refund - Health Insurance N/A N/A N/A
025 TPL Provider Refund - Causualty Insurance N/A N/A N/A
037 SUR Recovery - Provider N/A N/A N/A
Level I, Method 07 - TPL Refund Receipts 2 + 026 TPL Recipient or Relative N/A N/A N/A
027 TPL Direct Health Insurance N/A N/A N/A
028 TPL DirectCasualty Insurance N/A N/A N/A
029 TPL Direct Medicare N/A N/A N/A
Level II, Method 09 - Provider Cash Disposition 4 - 043 Provider Refund - Overpayment (23, 31, 95) 004-80-006 HSD DERIVED
TPL Provider Refund – Health Ins - Overpayment (24,
044 31, 95) 004-80-006 HSD DERIVED
Level II, Method 18 - Refund of Excess Funds 9 + - - 073 Refund of Excess Provider Rcpt. (20-25, 31, 37, 95) 004-80-006 002-80-005 DERIVED
Level II, Method 10 - TPL Cash Disposition 4 - 046 TPL - Recipient or Relative - (26) 004-80-006 HSD DERIVED
047 TPL - Direct Health Insurance - (27) 004-80-006 HSD DERIVED
Level II, Method 24 – Sys. Gen’ed Refund Drawdown 4 + - - 088 Offsetting Claim Adjustments (20-29, 31, 37, 90, 95) 004-80-006 002-80-005 N/A

Financial Procedures March 25, 2009 26-8
FIGURE 3 - FINANCIAL ACCOUNTING DECISION
TABLE
T 9 A C S DEBIT CREDIT FEDERAL
TRANSACTION TYPE P 9 R S P TXN DESCRIPTION ACCOUNT ACCOUNT ACCOUNTS

PAYOUT TRANSACTIONS
Level I, Method 02 - Payouts 1 + - 001 Cost Settlement HSD 002-80-005 DERIVED
002 Provider Payout HSD 002-80-005 DERIVED
093 Reverse Recoupment Made In Error ORIG 002-80-005 DERIVED

RECEIVABLE TRANSACTIONS
Level I, Method 01 - Advance Payment 5 + + - 015 Advance Payment - Manual Check 005-80-002 002-80-005 N/A
016 Advance Payment - System Payout 005-80-002 002-80-005 N/A
Level I, Method 04 - Gross Negative Adjustment 4 + 007 Carryover From Prior Fiscal Agent 005-80-002 HSD DERIVED
009 SUR Recovery - Provider 005-80-002 HSD DERIVED
010 Cost Settlement 005-80-002 HSD DERIVED
011 Provider Recovery 005-80-002 HSD DERIVED
012 Federal/State Audit Findings 005-80-002 HSD DERIVED
013 Fraud and Abuse 005-80-002 HSD DERIVED
014 Recoupment Set Up - Other 005-80-002 HSD DERIVED
094 Reverse Gross Level Payment 005-80-002 ORIG DERIVED
Level I, Method 15 - System Generated Receivable 8 + + - 080 Claim Receivable 005-80-002 002-80-005 N/A
Level II, Method 17 - Provider Receivable Receipts 2 - - 032 Cost Settlement - (07, 10, 80, 94) 004-80-006 005-80-002 N/A
033 Provider Recovery - (07, 11, 80, 94) 004-80-006 005-80-002 N/A
034 Federal/State Audit Findings - (07, 12, 80, 94) 004-80-006 005-80-002 N/A
035 Fraud and Abuse - (07, 13, 80, 94) 004-80-006 005-80-002 N/A
036 Recoupment - Other - (07, 14, 80, 94) 004-80-006 005-80-002 N/A
038 SUR Recovery - Provider - (07, 09, 80, 81, 94) 004-80-006 005-80-002 N/A
Level II, Method 22 - System Generated Recoupment 2 - - + 086 Claim Recoupment - (07-15, 80, 81, 85, 94) 002-80-005 005-80-002 N/A
Level II, Method 05 - Receivable Reversals 0 - 071 Receivable Reversal - (07-15, 80, 81, 85, 94) HSD 005-80-002 DERIVED

Financial Procedures March 25, 2009 26-9
FIGURE 3 - FINANCIAL ACCOUNTING DECISION
TABLE
T 9 A C S DEBIT CREDIT FEDERAL
TRANSACTION TYPE P 9 R S P TXN DESCRIPTION ACCOUNT ACCOUNT ACCOUNTS

VOID WARRENT
TRANSACTIONS
Level I, Method 11 - Void Warrant - No Reissue 3 - + + 050 Warrant returned by Provider 002-80-005 004-80-025 N/A
051 Stale Dated Warrant 002-80-005 004-80-025 N/A
Level I, Method 12 - Void Warrant Reissue 3 - + + 053 Mutilated Warrant - Reissue 002-80-005 004-80-025 N/A
055 Stop Payment Reissue 002-80-005 004-80-025 N/A
Level II, Method 03 - Reissued Manual Check 7 + - - 018 Reissued Warrant - (50-53, 55) 004-80-025 002-80-005 N/A
Level II, Method 23 -System Gen’ed Void Drawdown 6 + - - 087 Offsetting Claim Adjustments - (50-52) 004-80-025 002-80-005 N/A

Note - Txns 70, 82-84, 93-95 should reference the FCN of associated Txn(s) in the Comment field of the Add/Pay Screen.

( ) - Associated Financial Transactions
( ) - Parent Financial Transactions
HSD - Cost Center provided by HSD
DERIVED - The Federal accounts are derived from the cost center providered by HSD
ORIG = Account From Original Payout Transaction
TP = Transaction Type
99 = Provider 1099 Balance
AR = Accounts Receivable Account
CS = Cash Account
SP = Suspense Account
+ = Positive effect on Account Balance
- = Negative effect on Account Balance

Financial Procedures March 25, 2009 26-10