Steve's phone gave its distinctive internal ring.

"Steve! Hey! Happy New Year, man! Jeff here from Corporate AR!" the caller was speaking a mile a minute. "I sent you a critical email. Did you get it yet?"

"Nothing yet, but let me refresh Outlook," Steve S. clicked Send-and-Receive and waited for a moment. "Okay... yeah, I see it. Go ahead."

Steve gave the caller points for trying to hide his panic, but as things went on, it was quite obvious that something had hit some fan... somewhere. But for the most part, Steve mostly tuned him out. It wasn't the first "Jeff from AR" that he had spoken to.

Now make no mistake about it: Steve isn't an accountant, nor does he work with any financial systems on a regular basis. But the system that he maintains does, however, feed the corporate Account Receivable (AR) and General Ledger (GL) systems on a regular basis. Periodically, the bean counters reconcile the dollars in the AR system to what has been sent to the GL system as a sort of check-and-balance process and, almost always, everything is in sync. Almost.

In the first few days of January, it's the same song and dance. An email will land in Steve's inbox, and the source of the email is always who started within the past year or so. The subject is typically something ominous that makes the hair on the back of your neck stand up — **URGENT! CRITICAL ISSUE!** Billing System Clearing Account #12345678 for Business Units XYZ & ABC — and the email always comes complete with a few screenshots from systems that look as strange and foreign to a non-finance person as SQL would look to the person sending the request. However, the panic-worthy bottom line is always the same.

Jeff from AR continued, "the outage for Business Unit ABC is off by $1.3 million and I have no idea what is causing this. Can you please look into these items ASAP and let me know your thoughts?"

Of course, any time that a balance is over $1 million off, it tends to make anybody sit up and take notice. But for Steve, the feeling of déjà vu was quite palpable.

Did You Check the Logs?

Steve started into his research by asking, “When was the last time that GL was balanced against AR? And was it in balance?” While he never got a direct answer to that question, Steve eventually found out that everything seemed to be good right up until the end of December. “Were there any errors in the processing of the last GL file we sent you?” Steve asked, “ You know, the file that has the records with the effective dates of December 31st?”

“Not sure – I’ll have to check the processing logs and call you back” replied Jeff.

Moments later, Jeff called back and reported that the processing logs said that the problem was, Batch Consists of Posting Transactions in Different GL Periods. He snarkily added, "well, of course! That explains it. How could we be so stupid!?"

Steve thought the problem sounded familiar, so he called up the "GL Gurus" to look more closely at the problem and figure out what it meant. This is when some lights of recognition start to glow more brightly in peoples’ heads. “Hmmmm, it seems we’ve seen this before. What does it mean again?”

After lengthy debate, one of the gurus proclaimed “Oh, yeah, we can just change the dates in that file from December 31st to December 30th and then rerun the file.” So later on, lo and behold, the file processed cleanly and matched the GL 100%. Everyone was happy, vowed to remember to do that next year, and life moved on.

The 13th Period

This year, Steve simply had enough. He knew he wouldn't remember the issue the following year, and he was not content to just let the matter die.

Rather than sweep the matter under the rug again, Steve started doing some snooping on his own.  Eventually, he found someone who had archived an email from years past.

---------- Forwarded message ----------
From: Lewis Dodgson <[email protected]>
To: *GL-All <[email protected]>
Date: Wed, 2 Jan 2002 13:44:08 -0500
Subject: reminder—do not use December 31 as journal entry date
 
All,
It has been noted that we have received a couple of journal 
entries with a December 31 effective date. This is a reminder 
that using that date will post the journal entry to Period 13. 
Period 13 is reserved for business unit collapsing entries 
and Corporate year end entries.

Regards,
Lewis Dodgson
Assistant Vice President, Accounting & Operations

Amazingly, the GL system has special logic built into it based on the magic date of December 31st and it had been there for literally years. Steve wondered Didn’t anybody think that anybody processed transactions on the last day of the year? Why wasn’t this found out earlier? Sure there was turnover in the financial departments, but the gurus should have remembered the solution, after all, they were the GURUS for crying out loud!

Enough was now finally enough – Steve was now committed to do something, to keep this new year cluster&$^% from happening again. He weighed his options - Should he lobby for the dropping of the 13th period? How many systems would this affect? Could he make a case for such a project spanning different groups? Could he sell a techy reason for completely changing how the company did business to a bunch of stuffed shirts in finance?

In the end, rather than upset the corporate apple cart, Steve put in a simple change request so that his system won’t send 12/31/YYYY in any more GL files. If the system hits that date, it’ll use 12/30/YYYY instead. The GL system apparently doesn’t care. As long as as a date is “some time in December” and it’s not “December 31st”, things will be fine.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!