The Import File

CentralReach publishes instructions for building a QuickBooks import file. They work. What they leave out is the five things that will make your file wrong, and you will not find out until the P&L does not tie and you are three hours into a Saturday trying to work out why.

This is the whole method, including the parts nobody writes down.

Decide what you are importing before you export anything

The instinct is to recreate CentralReach billing entries as QuickBooks invoices. Do not.

ABA volume, payer adjudication, combined claims and secondary billing make invoice-level sync unreconcilable, and it will exhaust QuickBooks Online list limits inside a year. A practice billing 3,000 entries a month hits the wall fast.

The correct architecture: CentralReach is the accounts receivable subledger. QuickBooks carries a control account. You post summary journal entries and tie the control account back to a CentralReach export every month.

One more setup decision. Use an Other Current Asset account, not the native QuickBooks Accounts Receivable type. The A/R type forces a customer name on every journal line and pushes the balance onto the QuickBooks A/R Aging Summary, which then conflicts with CentralReach as the source of truth. You end up with two aging reports that disagree and no way to say which is right.

The export

Billing module, Billing screen, filter your date range, export. You get 178 columns. You need about ten of them.

• DateOfService, the accrual date. Not CreationDate, not FirstBillDate.

• ClientChargesTotal, gross charges at billed rates.

• ClientChargesAgreedTotal, charges at contracted rates.

• CalcAdjustment, billed less agreed. The contractual.

• AmountAdjustment, adjustments actually posted to the entry.

• AmountPaid, cash applied.

• NegAmountOwed, outstanding at agreed rates on a date-of-service basis.

• CopayOwed, patient responsibility outstanding.

• IsDeleted and IsVoid, the exclusion flags.

• GroupId and GroupCount, claim grouping.

The five things that make the file wrong

1. Deleted and voided rows

Filter IsDeleted and IsVoid before you total anything. The export includes them. Every practice that has ever asked me why revenue is overstated by four percent has skipped this step.

2. Agreed rates are not turned on

This is the big one, and it fails silently. If agreed rates were never loaded for a payer, CalcAdjustment is zero, the Neg_ aging series equals the DOS_ series, and the RCM report reports at billed rates with no label change anywhere on the screen. Revenue and A/R are overstated by the entire contractual allowance, which in ABA is routinely 20 to 40 percent.

How to check, in ten seconds: open the Billing screen and read the header. You need to see both Billed Rates and Agreed Rates, and both Billed Charges and Agreed Charges. If you only see one set, agreed rates are off. The setting lives in Billing, Miscellaneous. Only the main organizational account can change it. Check this before you build anything, because everything downstream inherits the error.

3. Mixing the aging series

CentralReach gives you four aging series and they are four different answers to the question what is outstanding. Use Neg_ for the general ledger tie: it is agreed rates on a date-of-service basis, which is exactly what the RCM report Receivables column produces, so the control account ties to the CentralReach summary with no reconciling item. Use FBNeg_ as the collections view only. It ages from first billed date, which matches the payer clock, but it will not agree to the RCM receivable. Pick one basis and hold it for the whole schedule.

4. Leaving out the copay columns

Every aging bucket has a _Copay twin. Insurance alone understates A/R, sometimes badly, and patient responsibility is the balance most likely to age out and become a write-off.

5. Claims the biller combined

When GroupCount is greater than one, the biller combined entries into a single claim. Reconcile at GroupId level or your entry-level totals will not match what the payer adjudicated.

The double-count trap

CalcAdjustment is a calculated difference between billed and agreed charges. AmountAdjustment is the sum of adjustments actually posted to the entry. If the practice maintains agreed rates and also posts the contractual as an adjustment at ERA time, the contractual appears in both fields. Book both and you have double-counted it.

Pick one convention per practice and write it down. Agreed rates maintained: contractual is CalcAdjustment, payer adjustments are AmountAdjustment less CalcAdjustment. Agreed rates not maintained: contractual is zero in the export, everything sits in AmountAdjustment, and separating contractual from write-off requires ERA detail.

Keep the three reductions to A/R separate

A contractual adjustment is the billed rate less the contracted rate. Known at billing, before any payer response. Contra-revenue. Never bad debt.

A payer adjustment happens at adjudication: denials, bundling, timely filing, non-covered services. Also contra-revenue, but track the avoidable causes separately. A timely filing denial is an operations failure, not a rate issue, and burying it with contractuals means nobody ever fixes it.

A write-off is an uncollectible balance, mostly aged patient responsibility. Three different accounts, three different conversations with the owner.

The entries

Revenue and A/R, on date of service. Debit A/R CentralReach for charges at agreed rates, credit Net Patient Service Revenue.

If the owner wants the gross-to-net walk visible on the P&L, gross it up instead: debit A/R for ClientChargesTotal and credit Gross Charges Revenue, then debit Contractual Adjustments for CalcAdjustment and credit A/R. Either way A/R lands at agreed rates. Do not do both.

Cash, in two steps. Debit Payer Receipts Clearing for AmountPaid and credit A/R. Then debit Operating Bank for deposits cleared and credit Payer Receipts Clearing. The clearing account holds the gap between a payment posted in CentralReach and cash hitting the bank. It should equal your unreconciled candidate payments, which gives you a defined balance to prove instead of a plug.

Payer adjustments: debit Payer Adjustments for sales adjustments in the period, credit A/R.

Write-offs: debit Patient Responsibility Concessions for aged uncollectible CopayOwed, credit A/R.

Overpayments: debit A/R for overpayments, credit Payer Refunds Payable. That last one is the entry everyone gets wrong. An overpayment is a liability, not negative A/R. Netting it inside the control account understates both your receivable and the refund you owe, and when the payer recoups it six months later it looks like a surprise. It was not.

What this costs every month

Pull the export, filter it, build the pivots, map the accounts, key five journal entries, tie the control account, chase the variance.

Three to five hours a month once you have done it a few times. Considerably more the first time, and considerably more any month a payer changes a rate or the biller combines claims differently than usual. It also breaks when the person who built the workbook leaves.

None of that is the fault of CentralReach. The export is complete and accurate. The work is in the translation, and the translation is the same every month, which is exactly the kind of work that should not be done by hand.

The version that takes four minutes

Qlarity does the translation. Export the same CentralReach billing report you already pull, upload it, and the revenue posts into QuickBooks Online at agreed rates on an accrual basis, broken out by funder, location and procedure code. Deleted and voided rows filtered. Duplicate-checked, so a re-upload never doubles your revenue. No PHI stored.

Thirty days free, then $199 a month. Start at getqlarity.app.

And if you would rather keep doing it by hand, the method above is the whole thing. It works.