On Periods, Reports, and Cash v. Accrual Accounting

[Dan Means]

Sorry -- thout I hit "reply all"...my bad...

Just for reference, I'm coming at this from a slightly different angle
-- I've been selling, modifying and supporting commercial accounting
applications in that 5 - 20 user "space" the big guys ignore for more
years than I should admit......

But the whole "cash vs. accrual" and "date driven" deal is where most of
the real people who use these systems get totally lost. The explanation
of cash vs. accrual was excellent.

It's extremely common in my world, that the folks who operate accounting
systems, are generally not accountants....so this whole transaction /
posting date did I close yet? stuff is the bane of my world -- they just
don't get it. 

So, at worst there might be 2 dates -- record the date that somebody
really recorded the transaction which may or not be equal to the
"posting" date -- the date the transaction really occured. (Audit trail
don't ya know -- how'd this entry get here?)....then the reporting
engine can sort out what's a "closed" year etc.




On Fri, 2003-05-23 at 21:28, Derek Atkins wrote:

> Hi,
> 
> Thanks for the reply.  It should have gone to the list, so I've
> forwarded it there.  In the future please be sure to CC the list
> when you reply to messages.
> 
> And yes, I acknowledge that a "13 period year" is something that we
> should handle for end-of-year processing.
> 
> I'm not at all convinced that date-driven reporting is cleaner, unless
> you mean Fiscal-date-driven (in which case I agree).  My point is
> that we need some sort of transaction effective-date and search under
> THAT date rather than the posted-date.  Yet once we start talking
> about effective dates, we might as well talk about Periods.
> 
> -derek
> 
> Dan Means <dkmeans at srsconsulting.net> writes:
> 
> > The period approach is how commercial packages handle this -- you can
> > define some number ot annual periods, and then attach a calendar date to
> > it. 12 is not always the correct number -- you might want monthly (12),
> > quarterly (4), or the infamous 5-4-4 (makes for even quarters even
> > though the months are off -- which could also mean 13 accounting periods
> > in a year...
> > 
> > There just needs to be a function that understands the dates.  Most
> > packages also have some sort of "adjustment" period -- the place where
> > all the year end tax mumbojumbo can be entered, which is not an
> > operational in nature, but usually things like depreciation expenses
> > etc. for tax returns -- but you have to keep your books in the U.S. the
> > same as your taxes....
> > 
> > But if you could build a reporting engine that just used the periods,
> > all would probably be okay, and if you messed up your period definitions
> > -- well then you could get odd reports...
> > 
> > Date driven reporting is usually just cleaner. A balance sheet is a
> > snapshot in time -- as of the close of business at a particular day. The
> > P&L should be representative of activities over a defined period of
> > time, perhaps a month or year. The balance sheet should be able to
> > determine the balance for accumulated retained earnings from the P&L
> > accounts...
> > 
> > Most commercial packages use some sort of metaphor for the "Year end
> > close" to get clean cutoff for retained earnings vs. current year profit
> > or loss...things can get dicey when people decide to "un-close"...or
> > change their definition of a fiscal year...which is very common...so
> > you'd need to add a "recalc" the period balances if it gets edited..
> > 
> > 
> > 
> > -- 
> > Dan Means	
> > SRS Consulting, Inc.
> > www.teamsrs.com

-- 
Dan Means	
SRS Consulting, Inc.
www.teamsrs.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20030523/a5dd8912/attachment.htm