Accounts Receivable Report With Future Dated Invoices

You can't come up with a solution of setting the report date to the future? You need us to tell you?

Thanks Allan. He needed that one.

That's a very poor solution for several reasons.

The whole reason for my question is that the user doesn't realize she made a mistake in the first place, and it would be nice if the Accounts Receivable Aging Detail report by default showed her that error.

In thinking about this more, I think this is a bug or a misfeature. If I have a future-dated invoice, in what sense is that invoice not part of my company's receivables? I could certainly understand a checkbox that allows a user to remove all future dated invoices from receivables, but by default I do not think it is correct logic to just assume that future dated invoices are not part of a company's receivables.

It doesn't have to be an error either. There are a lot of reasons why a business would use future dated invoices and enter them in their bookkeeping system a long time in advance.

An optional column in the A/R Aging Summary and/or Detail reports for Future totals would be a decent solution and a very useful feature. Don't expect QB to do this though. They're too busy manipulating market share to care about useful features.

==

Not a bug. Not a misfeature. You wanna see future dated receivables? Open the A/R account. They will be right there at the bottom of the register. And I suspect QB will even draw a line for you, so you can better see the mistaken data entries. As to thinking about it.. you should try it. You are creating an AGING report. Future A/R transactions are not aged.. they are not current, they are not 1-30, 31-60, 61-90, or >90. They are FUTURE. But you can overcome this. You can change the date to include future receivables. QB reporting allows the user to select the date range they wish. You can imaging the outcry if that capability were removed.

It is simply unrealistic to expect any software package to prevent or flag every error a user makes. If in your organization, future dated invoices "Occasionally ...get created by mistake, and I want visibility on that mistake" then it makes sense that you run specific checks for the errors your people commonly make. Or, better yet, find out WHY they are overriding the QB defaults of current date in order to post date an invoice.

No, it doesn't. The standard QB A/R Detail report opens with a screen allowing you to select a Report Date Range. The default is Today.

Change the date range on the report.

Willy Boy, you are an idiot.

If the totals on your aging report don't match the total on your Balance Sheet, it's time to go hunting.

So the report should include a section named Future. Future receivables are receivable. A report that provides accounts receivable detail and aging should show all accounts receivable, past, future, present.

Why are you defensive about this feature? Why would it hurt anyone to show future receivables in this report? As a worst case they could include a checkbox option in the customization dialog to exclude future receivables.

Today has two different semantics as implemented:

2) Act as a filter for screening out any receivable more recent than the specified date.

Those are really logically different things, and they should more logically be provided as two separate input fields, each which maps to the appropriate action. There is every reason for some users to not want to exclude future dated invoices, but to have the frame of reference for aging details be today.

No it should not. To you in your special limited case you consider them to be errors and want to find them. This is not the case in the big picture. A future dated transaction is not on the books and should not show on a report.

Perhaps you can't think of a reason ever for a future dated transaction. Taxes is the one that comes to mind real quick. Until the date the taxing authority sets, a tax obligation is not due, however you may know in advance when it is and how much it is and may want to enter it for future dated planing reports while not showing it on today reported reports of your actual obligations.

Don't like that example, here is a different one. You have an account with UPS. They send you a bill and on the bottom is says, "Do Not Pay, your bank account will be debited on FUTURE DATE" If you are like most people you are going to enter this future dated transaction right away. QB correctly accounts for it in cash flow forecasts (a forward looking report) and in reconciliation where it won't show because it hasn't happened yet.

The way QB does it is correct for the big picture.

As L has pointed out you can find them real quick by opening the register.

Because you are dealing with a bunch of anal retentives who can't grasp the concept that numbers are just data and people need to see them in whatever way is useful to them.

This Future A/R column may not be an ordinary bookkeeping practice for said anal retentives who have spend 3/4 of a lifetime adding up numbers with a calculator, but for a modern database application like QB should be (it isn't), this would be a useful feature worth adding to the program.

==

There is nothing special or limited about my case. If you asked 10 users which way they would want to see it I am sure at least eight would want to see future dated invoices on their AR reports. The only ones who might not want that are the ones who would have AR intentionally created for dates far in the future. And *that* is an unusual use of the product. Even a leasing company or someone who might need to do that probably doesn't create those invoices until they are due. And for those users give them a feature that doesn't look into the future. Not so difficult is it?

I think I'm looking at a bigger picture than your big picture. :) If I have an invoice dated two days from now, and it is due in 10 days, it certainly falls into the scope of what any reasonable business person would want to take into account when viewing a management report about how much cash is coming into that business. And whether they should or not, I'm sure most people are using the AR Aging Details as a proxy for predicting cash flows due in. To exclude an invoice that is due in 12 days based on technicalities is very theoretical, not very practical to the actual use. It would appeal to someone who cares more about strict definitions about AR (i.e., an accountant) than about money management for a business.

Again, I'm not arguing that you should not have a way to exclude future dated invoices. I can think of all the same use cases you can. But the user should exercise that choice about what falls into view.

To comply with your strict view of what should be in an A/R account, couldn't we have two separate input fields:

2) Define a date for purposes of calculating aging

That way I could set the date one year into the future and calculate aging from today, and I would use that to catch errors and to see any future monies due in far in the future.

Consider that there are different uses for this one report. One use is to produce a view of the AR account from the frame of reference of a particular day in time. The second use is just for money management. In the latter case you don't care at all about what accounting defines AR to be. The only thing you care about is projecting cash flows into the business for the next 90 days, and in my initial example catching potential data entry errors.

receivables.

Quite true, and after all isn't that philosophy why Quickbooks completely wiped off the face of the map 20 other small business accounting programs in the early and mid 1980s? Those packages all focused on getting accounting details precisely correct. Quickbooks relaxed the accounting rigor and focused on information people need to run a business.

Bullshit. Not only don't you know what you are talking about, your an idiot to boot. If behid the scenes QB didn't peform like a real accounting package it would not be on the market today. Intuit, going all out to shield the every day user from the fact that QB is a true accounting progrm is a far cry from "relaxed accounting rigor".

"behind the scenes" would be the key part of that.

Can you explain the accounting theory that says an invoice dated two days from now and which is due 12 days from now is not part of our accounts receivable?

There is a fundamental difference between a balance sheet view of an accounts receivable, which can by definition only include transactions dated today or earlier, and a report that is loosely based on accounts receivable whose purpose it is to help a business person get a future view of cash coming into a business.

I understand the difference between those two things. I understand that a balance sheet must have a rigorous definition of AR and that the balance sheet view of things must apply those rigorous definitions. I also understand that a report whose purpose is to help understand cash coming into a business can provide at least an option to cut certain corners in order to give someone very useful information about a business.

Now Intuit can rename the report and take AR Aging out of the name for all I care, if that makes the accountants happier with the result. I just want the information on future receivables in order to run a business.

And from your description I would say I'm nothing like your wife. I compromise and make due with things in an imperfect state constantly. I'm not asking for Intuit to do something custom for me. I'm asking Intuit to ask 10,000 customers just like me if an invoice is dated 10 days in the future and due in 20 days, do they want to see that information when they report on receivables. I'll gladly bet anyone $500 that 8,000 of those customers will answer that very specific question with a yes. So then it's Intuit's problem about how to do what the vast majority of their customers want them to do in a way that makes purists happy too. I know there is some solution that would make both camps get what they want. It's not my problem to find that solution.

I understand the issue now. It's the difference between a balance sheet view and a cash flow projection. I'll qualify my remark in response to another post here.