Why can’t I log a payment for a future date? If I set up a BACS or FPS payment for tomorrow, I should be able to log the payment against tomorrow’s date, so that it matches the eventual bank record.
Because there’s no gaurentee a future payment will happen.
If you allowed to tag future payments a whole host of errors would follow. Unexpected payments that result in unpaid standing orders, assumption of payment dates and different actual dates resulting in missed or doubled up transactions from bank feeds. The list is endless.
It’s an accounting system, not a real-time information system. I should be able to choose whether I need that kind of protection. It’s profoundly irritating to, say, set up future payments for 50 invoices and not be able to flag them as paid, knowing that instead I will have to hand-allocate each payment to the relevant invoice when I do the bank rec after the payment date, even though I’m looking at the invoice right now and could simply flag it as paid. It also means I can’t send notifications to suppliers automatically.
Any failed payment would show up in the bank rec, at which point you could unwind the forward payment record and the associated connection to the invoice. After all, you can happily make forward journal entries into bank accounts, so it’s not as if there’s no opportunity for this kind of error.
Further evidence for this is that it doesn’t actually break anything in QuickFile if you do log a forward dated payment (the “paid” tickbox on the new purchase creation screen allows you to manually enter a future date, even though the popup date chooser doesn’t) - it’s a policy restriction rather than a technical one.
I Apreciate that for some one like you, it may not cause many issues. However I can see situations where other users will log future payments instead of using actual bank feeds, and shoupd they do this all the time, will have massive errors should they get it wrong.
Vat cash accounting is another area where this could fail, given you may pay vat on money you think you’ll rexeive in one month, but doesn’t actually get paid that month, and vise versa.
I personally hate that QF allows you to log any sort of payment manually against an invoice without at least tagging a payment directly from some sort of bank feed or transaction list, and if this were extended to future payments I can see users getting in some right mess.
This of course is my personal opinion and obviously doesn’t affect anything qf may consider reviewing and implementing
Though this is handy for things like payments received in cash where there is not (and can never be) a feed. Yes you can manually create an untagged transaction in the cash “bank” account and then tag that but it means having to type the amount in two different places.
What I meant was, when you mark an invoice paid from the invoice screen and pick bank account it creates a transaction for that payment, if you also use bank feeds you’ll duplicate thaf payment and will have to delete the untagged one.
Things like cash I’m not so bothered about, as in theory any payments made or received in cash would appear in the cash account and would probably be left to its own devices.
Like I say I Apreciate some people here can handle that but for a novice user it quickly becomes full of errors, which I and other accountants see quite often when tidying up clients own book keeping.
The inverse of this is my whole problem. I usually set payments up to go tomorrow, so that I have time to do a second pass and check I’ve not made any errors. For ease, I mark the invoices as paid as I go along, since this makes it easier to keep track of what’s outstanding, and I can send a payment note to the supplier. If I could set the payment date forward, I’d get a bunch of duplicates in the statement import (I don’t use automated bank feeds - the very idea gives me the heeby-jeebies) which I could safely skip. Instead I end up with untagged payment records for the correct transaction date alongside the one-day-earlier manual entries; I either have to delete these manual entries and retag the imported payments, or delete the imported payments and live with a bank rec that’s incorrect when considered daily. I do the latter, since I’m only really interested in being accurate at month end. Since we do a monthly payment run, there are (relatively speaking) a large number of these payments and it’s a pain in the 'arris - and I dislike not having my actual bank statement perfectly replicated in the QF records.
1 Like
Depends. If there is a matching transaction it asks you to link to that one, if there isn’t one it just creates one. I’ve brought this up before here and there as the UX is poor here, you don’t actually know what will happen when you click that button before clicking it.
1 Like