POST-DATED CHECKS ARE ACTUALLY A PROMISE NOT CASH
Once I add the checks under receipts and give the status as ‘Pending’ this reduces the value from the customer’s outstanding.
Shouldn`t it reduce from the customer’s outstanding once the cheque is honored? (converts to cash in our account upon deposit)?
STATUS FOR DISHONORED CHEQUES:
Suppose the cheque was dishonored by the bank, what is the procedure? is there a cancel payment option in the receipts?
BANK CHARGES FOR DISHONORED CHEQUES
Banks charges are applied for dishonored checks, I am aware we will have to expenses the bank charge from our account but how do we post a bank charge to a customer’s account? as this will need to be claimed from the customer?
This is dependent on local law. In many jurisdictions, it is illegal to write or deposit post-dated cheques. If they are legal in your jurisdiction, whether to enter them as accounting transactions before their issue dates is a business decision, not an accounting one. That decision depends on whether you consider the obligation to be discharged, as well as whether the bank will accept post-dated cheques for deposit. There may also be local accounting standards that influence that decision.
No. That is why the program includes the Status field. Unless you are holding the cheque until the issue date before depositing it, you have accrued the receipt, whether or not the cheque has yet cleared. This is like accruing income when the sales invoice is created, regardless of whether the customer has paid.
It is sensible that the system allows to add the receipts (cash or cheques) However it is more appropriate if the system has an option to approve or decline a receipt / payment based on the result that takes place (honored / dishonored etc) until then not deduct the balance from the customer’s outstanding.
Also it would be nice if the system can introduce debit memos to raise against customers for bank charges and other entities that see fit, instead of raising separate invoice.
This would just add another layer of complexity without benefit. You already have the option of whether to record the transaction. If you do record it, you have the ability to record status. Why introduce a third layer? Besides, when a cheque is dishonored, more actions are required on your part than simply checking a box to invalidate the transaction. At that point, you have already deposited the faulty cheque with your bank, so it cannot be ignored.
This, too, would be more complexity without benefit. Such a transaction would have no functional difference from a sales invoice. You would need to enter all the same information, regardless of what the form is called. If you want to call such a transaction a debit memo, change the title on the sales invoice.
It is also worth noting that calling something a debit memo risks confusing such a transaction with a debit note, which has a totally different purpose.
You see the customers here 99% of the time pay post-dated cheques to settle their invoices.
We do not consider this payment until the cheque realizes. weekly once we review the outstanding against two criteria
credit period allowed against the invoice
credit limit assigned the respective customer
if either one is exhausted we do not proceed on sales orders until
The cheques are realized or,
The customer agrees to purchase the new order in cash (until the issued cheques realize and is below the allocated credit limit / within credit period)
In terms of Manager my only concern is when the customer pays in post-dated cheques it immediately deducts from the debtors outstanding, so if we are to review it will show as if the customer has fully settled all is outstanding and he can repurchase.
These settlements cannot be compared to the accrual basis accounting concepts. On an accrual basis accounting, the goods that are released has an actual value whereas the cheques we receive are just a piece of paper that will not be of any value until the supported bank acknowledges it.
I think the manager’s approach of accepting receipts is valid but deducting the value under pending status is not.
I think that what you are requesting is something that exceeds the payment module of an accounting program also given the fact there may be even some errors in the way you account checks.
First of all a check is not a cash payment neither a bank payment but it is a form of credit you have against a client, given also the fact that you don’t have the money in your pocket.
So you should account it as:
Credit for checks to be cashed Vs Accounts Receivable
Secondly you have two cases:
a. You successfully cash the check and so you will have Receipt (Cash at Bank) Vs Credit for checks to be cashed
b. The check was overdraft and so you will have Credit for checks to be cashed Vs Credit for overdraft checks (unlikely to pay)
All that given, what you are requesting to be put inside Receipts module is out of place. Otherwise there should be a specific module for Clients Checks. But it’s up to @lubos to decide if all this development work is worth for this particular scenario or you should register the movements with journal entries.
@Premm, you have not said what you do with a post-dated cheque while you wait for the issue date to arrive. Do you deposit them in the bank, and does the bank accept them? Or do you hold them?
If you deposit them, that indicates your expectation that the cheque will eventually be cleared. So it is Pending. If you hold them, that is like having no cheque at all, so no entries should be made in Manager until you deposit them.
Perhaps you also need to review your policy on how much credit to extend to customers, considering the amount of future-dated cheques you already have.
@Tut we hold on to the checks until the date arrives. credit limits are planned and reviewed semi-annually (based on sales performance history & increased or decreased based on the outcome)
The thing is we immediately issue a temporary receipt to the customer once we collect the payment just for acknowledgment purposes, so as per you the only way to keep track is to maintain a separate spreadsheet to keep track of these payments until the date arrives?
But in this way, based on your local law, you could have many issues:
In many countries it is illegal to have null accountings in the daybook
you don’t keep track of the history, ie you edit an entrie instead of adding one when a second step happens (btw this is a fundamental of double entry accountings)
You don’t have a solution if the check is overdraft, if not to delete the Receipt
While it seems functional under a practical point of view it is very borderline under an accounting one.
To me it is constant with having a 3 state rather than 2 state cheque clearance.
Cheque given to supplier but future dated (so not legal tender). Supplier doesn’t pass cheque to bank. Enters it’s current value in Manager (zero) but records it’s likely future value in a custom field.
Cheque date reached. Supplier banks check and updates amount to it’s current value. Marks cheque as not cleared
Cheque cleared, marked as such in Manager or cheque rejected and treated as such in Manager.
Logical to me but I’m not an expert in all local laws.
My point exactly, besides PD Checks are not considered payments here, so I think this will not affect as per Patch’s advice. Either this or I maintain a separate spreadsheet with all the cheques and add against the outstanding to find the actual value. The former will have less work than the latter!
I have to point out that you have no control over what a supplier does with your cheque. This discussion only applies to cheques received from customers.If you were referring to the business as the supplier in a transactional relationship, what you have described is functionally no different from what @Premm is doing now—holding the cheques until their issue date arrives.
Your description of post-dated cheques was telling: “…not legal tender.” Would you enter a receipt if the customer gave you Monopoly money?
I found @Premm’s later comment enlightening, because it essentially matched your own description: “PD Checks are not considered payments here….” If they are not considered payments, why would you want them entered in your accounting records?
