I'm no accountant, but in my system, every line item in the transaction detail  table is either a charge to the patient/customer, in which case it has a positive currency value, or it is a credit to the pat/cust, in which case it has a negative currency value, or it is a free item, where it's amount is $ 0.00. 

A partial payment, whether cash, credit card, check or what have you, is just a negative currency value that partially offsets the account balance (which is nothing more than the arithmatic sum of this one column). To get the A/R balance, account balance, remaining due, whatever you want to call it, you just sum that column for the particular account.  To get the total  of sales for the day/week/mo/whatever, you just sum only the rows having positive amounts; to get the total money received, just sum those rows showing a payment.  To create a bill/statement/invoice, just sum every row for that pat/cust. Everything is done "on the fly", and no other tables are needed. I also use the same view to print insurance claims (HCFA, etc), but in these cases, the full price amount (U&C, usual and customary) is submitted rather than the discounted amount.

For cash based systems, partial payments are no different from full payments or overpayments.  They are all income when received.  For accrual systems, you just total the amounts charged when charged, and only use the payments as a way to calculate the year end adjustment for bad debts/discounts/etc.

Actually, I do use another table that mirrors the transaction detail table for documenting printed statements. It is only needed to resurrect/reprint a previously printed statement/invoice/superbill.

Again, I'm no accountant and I'd appreciate hearing of any flaws to my thinking here.

Bill

Ben Petersen wrote:
Hi Bill,

My question really relates more as to how partial/over payments against 
invoices are treated in the general ledger for cash based systems, rather 
than billing. (What do you do with the cash?) But Thanks!

Ben Petersen


On 19 Aug 2003, at 9:57, William Stacy wrote:

  
I use a transaction view that includes  a transaction table and a 
transaction detail table.  In the detail table, all chargable items have 
an item number (that links them to other, item tables), a quantity,  a 
regular price/fee/amount per unit, a computed column that is the product 
of the quantity and the price, and a final price (discounted/agreed amt, 
etc). All payments and other credits receive negative signs and go in 
the final price column, so the "balance" of a transaction is simply the 
sum of the price column, which will be positive if a balance remains, 
negative if a credit balance is created, and zero if the payment/credit 
totals equal the charged amounts.  This way I can create statements, 
bills, insurance claims etc from this one view.

bill

Ben Petersen wrote:

    
Hi all,

I'm down to the nitty gritty of an accounting package and wanted to make 
sure my take on accounts receivable for cash based customers was 
accurate.

For straight up transactions where there is an invoice and a payment for that
invoice nothing hits the GL until payment is made. But in the instance where
someone _partially_ pays an invoice, or, over-pays an invoice, this is what
I've been doing in past systems:

Debit cash for the payment amount.
Credit A/R for the payment amount.
Debit A/R for the invoice total.
Credit income accounts for the items on the invoice.

In the case of under-payment this leaves an A/R balance. In the case of over-
payment there is a negative A/R balance. 

In my re-write everything is driven by views, so it is possible to have a
circumstance where new invoices work directly against the customer account to
reduce the credit and not be posted through A/R. My concern is that while it
makes the A/R portion of the GL cleaner, it is possible, for example, to have
an invoice detailed in A/R at one moment, and not the next, if a new invoice
brought the customer account to zero. While the transactions would explain
"what happened" I don't know that this is acceptable.

I'm looking for some outside confirmation and/or alternatives.

Thanks

Ben Petersen

.

 

      

.

  

Reply via email to