Unique Business Challenges and General Discussion

[SRYork]

For me to make sense of this, I think of the AP / AR module, journal / update process as a subsidiary ledger that periodically posts to the general ledger.  That explains why there is a separate general ledger register / update that must be performed to actually update the general ledger.  The general ledger registers can be posted in detail or summary. If you want to tie your GL Transaction detail to the actual document, this option should be set to post in detail.

In order to have the GL Posting Date to be the same as the document date, simply set up a batch for each day (instead of period) that are on the documents included in the module journal.

[TomTarget]

I would agree that 99 times out of 100 that the Vendor's invoice date should be the same as the date you want it to be posted to the general ledger.    However, it's not uncommon either to see a vendor invoice be dated other than the date the actual service was provided.   They really should be the same,  but I can't control what my vendors do in their own accounting system.

In those situations I want the the posting date to be the date the service was actually provided (for proper accrual accounting) however when determining due dates you still want the invoice date to be what the vendor put on their invoice,  thus the ability to have the differing dates.

The other situation I can think of where the dates might be different is with regards to FOB destination items.  The vendor will probably make their invoice date be the shipping date (they don't know when the items will actually arrive),  but for your own purposes you want the G/L posting date to be when they arrive,  but you still need to have the invoice date be the vendor's date.  This probably isn't an overly common situation (especially for people being on the lookout for it),  but the flexibility is in the software to handle it.   You just have to be careful that you don't unintentionally mismatch the dates.

What would be a good idea would be to have the program issue a warning that the dates MAY be mismatched.   Hmm,  that would be an interesting project to explore for scripting.  I've toyed with this concept in various modules but never had the time to explore it fully.    The closest I've come to this is creating a script that looked for a receipt of goods entry that was more than a couple days out of sync with the current date.

[RosieD]

This goes back to accounting.

MAS has 12 posting periods.

To make your financials easy to understand, you'll want to make sure that your AR (or SO - wherever you're entering the customer invoice) date is in the SAME PERIOD as your invoice date.

For example, if your invoice date is 9/20/11, then your AR (or SO) date on the actual module needs to be set at somewhere between 9/1/11 and 9/30/11. 

You can make an easy check at the end of the month by comparing the total of your A/R trial balance to your accounts receivable GL account.   Then check the AR trial balance against the AR aging.  If any of the three do not match, you may have posted something into the wrong period.  I do this at the end of every period after I've gathered any 'last minute' revenue to post.

You could just make a journal entry to correct the GL to the AR trial balance (or aging, though I'm wincing at the thought of it) if necessary, or just detail what the reconciling items are on a monthly basis.

[RosieD]

Wanted to add, you should be checking your AP trial balance against the GL and aging at the end of the month as well.  Those reconciliations are really necessary.  Make journals to accrue/adjust as necessary... 

AP is a little more awkward than AR, in that you really don't get all your AP invoices at the 30th of every month - no one does.  It's pretty hard to separate your AP into 'invoices from prior month' and 'invoices from current month' in the first week or two of every new period though.  Most people don't do that.  The AP trial balance should show the correct AP amounts for the end of the month ... not the aging.