Lost Checks - No Payee - Best Practice

[Milton Stern]

I appreciate your analysis.

Personally, I would would like to be able identify any possible fraud by a
Payee and/or Amount mismatch, or an "out of range" Check Number" at time of
reconciliation, all within the same database.

BTW We are talking about 50 checks. (For some reason it expanded to 100
then 500)

;-)

Everybody's help is very much appreciated.


On Mon, Jun 8, 2015 at 11:32 PM, Buddha Buck <blaisepascal at gmail.com> wrote:

> May I suggest thinking about how you do fraudulent check identification?
>
> Here are three scenarios:
>
> In all three cases, you have previously written checks numbered 1001
> through 5000, as well as checks numbered 5501 through 5672. All but 10
> previously written checks have cleared the bank, and the oldest uncleared
> check is 5563, and is 5 months old. Checks 5001 through 5500 were lost in
> the mail, and your bank doesn't honor checks dated over 6 months ago, nor
> do they track cashed check numbers longer than 6 months.
>
> Scenario 1) A fraudulent check is cashed by your bank numbered 5345 and
> dated for last month.
> Scenario 2) A fraudulent check is cashed by your bank numbered 5563 and
> dated for 5 months ago. The payee and amount differ from the legitimate
> check 5563
> Scenario 3) A fraudulent check is cashed by your bank numbered 5683 and
> dated for this month.
>
> Assuming, as you claim, you can't trust the bank to identify a fraudulent
> check, how can you detect the fraudulent check in those three
> circumstances?
>
> The bank cannot detect that checks 5563 and 5683 are fraudulent, as both
> are reasonable check numbers, have not been cashed previously, and are
> within the right date range. Arguably, 5345 also can't be detected for the
> same reasons. Detecting them is up to you.
>
> For me, detecting them would come when I examine my bank records, either
> at reconciliation time or within the month, and mark outstanding bank
> transactions as cleared. This involves matching open transactions in my
> records with new transactions in the bank records. For checks, I can search
> by check number. In the case of check 5683 and 5345, I would not find a
> matching transaction. For check 5563, I would find the transaction, but the
> data would be wrong. All of these cases tell me Something Is Wrong, and I
> need to investigate (did I err in data entry? Is there a bank error? Was
> there fraud? Did I forget to enter the check? Was the check number part of
> the missing block of checks (and, thus, fraud?)).
>
> I fail to see how entering 500 voided transactions into GnuCash would make
> that job easier.
>
> On Mon, Jun 8, 2015 at 8:19 PM Milton Stern <drmoshe5 at gmail.com> wrote:
>
>> Thank you for the explanations.
>>
>> It gives me a bit more of a picture of how things integrate.
>>
>> I deal with information systems and databases, and frequently look for
>> integrated tracking, checks and balances.
>> I was just trying to find the best way of tracking of a jump in check
>> numbers, with easy identification of possible future fraudulent check
>> writing. (I don't trust the bank to identify a fraudulent check. Banks
>> frequently cash checks that are even missing signatures, dates and have
>> wrong names.)
>> I am trying to avoid maintaining 2 databases for this purpose. Since I can
>> not use a blank transfer account transaction, nor the "Orphan" account, I
>> guess a separate payeeless Voided Check account may be my best option.
>>
>> Thank again,
>>
>> Moshe
>>
>>
>> On Mon, Jun 8, 2015 at 7:06 PM, John Ralls <jralls at ceridwen.us> wrote:
>>
>> >
>> > > On Jun 8, 2015, at 12:31 PM, Milton Stern <drmoshe5 at gmail.com> wrote:
>> > >
>> > > Thanks for the suggestion Fred.
>> > >
>> > > Re:"Why would you want a second account anyway? A txn with zero value
>> > does
>> > > not require a balancing split in another account."
>> > >
>> > > But, it seems that if I do not assign an account for transfer, it
>> > defaults
>> > > to "Orphan".
>> > > --
>> > > And, thanks John for the standard accounting info. I am not an
>> > accountant,
>> > > and would be a classified as a newbie in accounting lingo.
>> >
>> > Me either, but I am a GnuCash developer. In this context “Orphaned Gains
>> > XXX” and “Imbalance XXX” aren’t standard accounting terms, they’re the
>> > names of the accounts that GnuCash uses — to the point of creating if
>> they
>> > don’t already exist — in the situations I described. I failed to explain
>> > that XXX is replaced with the three-letter ISO code for the currency in
>> > which the gains or imbalance is denominated, and that those are the
>> English
>> > names; others are used if you’re using a different locale.
>> >
>> > Regards,
>> > John Ralls
>> >
>> >
>> _______________________________________________
>> gnucash-user mailing list
>> gnucash-user at gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> -----
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
>
>