Surely a receipt-tracking compromise will allow ebasers to reap the
simplicity and efficiency of ebase and provide the controls of the
accountants who need reliable records.
For me, the minimum requirements are:
- use ebase for all "payments" (bank deposits) and numbered
receipts
- use ebase Control Reports of "payments" (daily, weekly,
monthly, etc.) for tracking control showing receipt #'s, etc. (A bank
deposit report and a receipt sequence report, for instance)
- use the accounting records for recording summarized total
ebase "payments" (daily, weekly, monthly). The ebase Control Reports
provide the accountability for the auditors.
- restrict deletion of ebase "payments" records until Control
Reports are printed (better still, restrict "payments" deletions for at
least one year until the audit is complete)
- do not change ebase "payments" records after ebase Control
Reports are posted to the accounting records (e.g. if a cheque bounces,
record this in a new Adjustments "payments" record using a negative
amount and the old posting date - this "voids" the original payment and
a note can be made on the original record when if it is adjusted)
- if necessary, have a field on the "payments" record matching
the record to a specific bank deposit or accounting entry (use a date or
other unique number code). This field would exclude or identify
adjustment records in Control Reports)
Perhaps others can suggest a simpler approach but for me the key goal is
to make one entry for each transaction with a contact - preferably in
ebase. Accounting records normally do not need the individual deposit
or receipt details. (There are exceptions - if receipts for
publications, etc are better tracked in the accounting records for
inventory control then go that route. These exceptions may not be
critical for ebase contact management but if they are they can also be
entered in ebase with unique controls to distinguish them in Control
Reports)
In a way, I think of ebase as a cash register. Ebase print-outs give a
regular summarized report of transactions affecting the accounting
records. Hard copy print-outs keep the auditors happy and are
technologically neutral - often audits do not occur for one or two years
after the transaction date and accessing historical computer records can
be problematic.
At least one flaw exists in the above approach. It also exists when
individual receipts are entered directly in the accounting records. The
flaw is that organizations may issue "invalid" receipts "for income tax
purposes" (duplicates or with errors) that are not entered in either
ebase or the accounting records. The use of pre-printed serially
numbered receipts is often suggested to control receipts. This can be
inefficient if the receipts are not convenient for computer processing.
- For example, we use ebase to print the receipt on the bottom of each
acknowledgement letter.
Needless to say, with the above approach, we avoid the problem of trying
to figure out how to transfer data between ebase and our accounting
software - in our case Quickbooks. Recent support list messages with the
subject "ebase and Quickbooks" describe other factors some organizations
face in selecting the best use for ebase and their accounting software.
Gerry A Hodgson
8871 Gay Road
Richmond BC V6Y 2H8
Canada
[EMAIL PROTECTED]
604-271-9877
-----Original Message-----
From: Walt Daniels [mailto:[EMAIL PROTECTED]]
Sent: November 24, 2001 6:33 AM
To: TechRocks Support
Subject: [support] RE: Receipts Tracking
Ebase's accounting functions are too weak to satisfy users, much less
auditors. You really need to be doing your accounting on a program that
is intended to do accounting and preferably one that your auditor agrees
meets their requirements.
> -----Original Message-----
> From: Peter Kidd [mailto:[EMAIL PROTECTED]]
> Sent: Friday, November 23, 2001 5:17 PM
> To: TechRocks Support
> Subject: [support] Receipts Tracking
>
>
> The question in here is how to track recipts (I think) -- The Receipt
> No field in Payments is an automatically generated serial number
> field, and is a unique number that identifies a transaction. If you
> delete a payment entry, then it appears to just evaporate. That means
> you can't account for every receipt by this "Receipt No". Sometime
> back on this list, it was said that it was only named Receipt No, it
> wasn't actually a Receipt No, in the sense of issued receipts. So how
> do people use eBase to account (satisfy their auditor) for receipts
> issued, besides a gapless sequence of numbers?
>
> ------------------
> Reminder to each recipient: To change your list account preferences,
> go to http://email.sparklist.com/scripts/lyris.pl?enter=support and
> enter the email address you used to subscribe to the ebase support
> list:: [EMAIL PROTECTED]
>
> To unsubscribe send a blank email to
> [EMAIL PROTECTED]
> ---------------------------------------------------------------------
> ebase - Relationship Management for Nonprofits, http://www.ebase.org
> ---------------------------------------------------------------------
>
>
------------------
Reminder to each recipient: To change your list account preferences, go
to http://email.sparklist.com/scripts/lyris.pl?enter=support and enter
the email address you used to subscribe to the ebase support list::
[EMAIL PROTECTED]
To unsubscribe send a blank email to
[EMAIL PROTECTED]
---------------------------------------------------------------------
ebase - Relationship Management for Nonprofits, http://www.ebase.org
---------------------------------------------------------------------
------------------
Reminder to each recipient: To change your list account preferences, go to
http://email.sparklist.com/scripts/lyris.pl?enter=support and enter the email address
you used to subscribe to the ebase support list:: [email protected]
To unsubscribe send a blank email to [EMAIL PROTECTED]
---------------------------------------------------------------------
ebase - Relationship Management for Nonprofits, http://www.ebase.org
---------------------------------------------------------------------
