Form defaults for reports

“Form defaults” for “Reports” should at least allow specification of

  • Accounting method

The use case is:-
When I do accounts for a business I make a business decision outside of Manager if I am going to submit account to my tax authority on a cash or accrual basis. After that external decision has been made I will want all reports to default to that selection. I appreciate that some users will have a need to set up their business for Cash or Accrual accounting and occasionally need a report using the alternate standard but using other than the Business default is a relatively rare exception.

The default selection should apply to

  • Summary page
  • Profit and loss statements - all reports defined
  • Balance sheet reports - all reports defined
  • Changes on Equity - all reports defined
  • Trial Balance - all reports defined
  • Tax audit - all reports defined
  • Tax summary - all reports defined
  • Tax Reconciliation - all reports defined
  • Tax Transactions - all reports defined
  • Tax Sales per Customer - all reports defined
  • Taxable Purchases per Supplier - all reports defined
  • Custom Reports - all reports defined
  • Report transformations - all reports defined

In Manager this work flow is currently difficult to implement and error prone for two reasons

  • While it is true at set up time when there are no invoices yet entered, the selection does not effect current values. The issue is when an invoice is entered in the future I do not want all reports (or or worse some I missed) to produce erroneous results at some time in the future.

  • After an invoice has been entered and I enter the accounting method I’m using with the tax authority into the summary page. New reports still do not respect this decision. Should I forget to change the selection on any of the above reports, I will then distribute false reports.

Delete the following as it was not really relevant and a distraction

It could be extended to include

  • Report Period with column name and comparator periods
  • Report date with Column name and comparator dates
  • Using a terminal value for reports which don’t allow comparator columns
1 Like

I get the impression that this has happened at least once before, which I’m sure would be quite frustrating.

When I create a new report (e.g. P&L report), I can choose my accounting method. Then I just click View and it remembers the one that I selected. I can change it at any time using Edit.

My business currently is reported on a cash basis, but new reports default to accrual basis. So I can understand what you’re saying. But when I’m viewing a report, the ones where it has a financial impact on the results will show clearly if it’s cash or accrual basis and it’s easy to spot such mistakes.

I agree that it would be nice to have new reports default to cash basis in my scenario (and in your scenario), but at least for me I feel like it’s very minimal impact since after a report is created it remembers the selected option.

Unless you generate a new report from your Manager business file and send it out (or don’t immediately notice). The consequence of which is negative both in my and my contacts time but also Managers reputation.

Yes, I agree. That is a pretty negative impact.

Still believe that it’s not a massive problem, though. As it’s just a default value.

I disagree strongly with this suggestion. In my lengthy experience with the program, I very frequently have need of reports with unexpected parameters, including accounting basis, beginning and end dates, and comparative columns. While I can predict a set of standard financial reports at the beginning of an accounting period, those are easily handled by cloning and slight editing. But by far the majority of reports I have created over the years have been in response to unanticipated management needs, external requirements of government or financial institutions, or changing demands of regulators. If I had set up defaults for reports, I would definitely have spent more time undoing them and overlooked forgotten choices than is now the case.

I also disagree that Manager’s reputation suffers when a user makes a mistake on a report. An external recipient of a report has no idea what software was used to generate it. Thinking of my own experience, when I see a mistake on a report, I never blame the software; I blame the user. This is a case where either the current implementation or your suggested one could result in similar mistakes, emphasizing the need for care.

In the most recent example, I encouraged my accountant to install Manager to access my accounting data. Reassuring him it was easy to use and the desktop version was simple to setup.

He had a report printed off for comparison then noted one of the accounts had a different value than expected. After some work identified it as a difference of transaction dates.

Seeing that my accounting software was set up to produce reports in Accrual based accounting offered to change their processing to match.

The solution involved explaining you can’t set a businesses accounting method in Manager, you have to remember to set it every time you generate a report. Some what inconsistent with the behaviour expected of a professional software in my opinion. The resulting fee for time wasted probably exceeding a year’s software subscription cost.

An earlier example was setting up Manager, finding the accounting method could not be specified because “It makes no difference when no invoices are entered”. Using Manager for some time, creating and cloning reports. Later finding occasionally entering invoices was useful. Then finding all my old reports and their clones were now falsely labeled.

How a businesses elects to report to their tax authorities should be entered into Manager when the decision with the tax authorities is made not at the software elected time.

So you would be best served by leaving the dates at their setup default.
Any how date range options are less critical to me than being able to set a businesses default accounting method.

This statement is not correct as the accounting method can be selected in the summary screen and all reports at the point before anything at all has been entered into a newly created business file. The selection is then respected from the point when the first transaction is entered into either the customer or supplier module.

I don’t think that it is necessary to introduce Form Defaults for reports because once the first report is created it is effectively a form default because of the clone function, so having form defaults for reports would be redundant functionality.

I think there are a number of issues here:

  1. At no point does the Summary screen indicate an accounting basis. It should always state the accounting basis that has been selected under the edit tab.

  2. Reports do not state an accounting basis, in the header, until a transaction has been entered for either customers or suppliers. Reports should always display the accounting basis that has been selected in the report definition.

  3. The default accounting basis for reports is always set to accrual basis. There should be an item in the settings tab where a default accounting method can be set for reports, but not the Summary screen.

By having a form default which effects the summary screen; what I envisioning is the only change from current behaviour is when Manager first shows the option (when an invoice is entered) it is set to the cash or accrual based on the form default setting. No other effects are envisioned by me here (although I’m not necessarily against them). Users could still change it. When that option can be first changed becomes less important to me if it will be set to a value consistent with my tax authority declared accounting convention.

Similarly for reports. Having a form default for cash/accrual only effects when a new report is generated. The user can still change it should they need a report in the other convention. They could also change the form default if they changed the reporting convention with their tax authority.

This is almost a side issue, but the cash/accrual accounting basis can now be set before any invoices are created. This is how things were years ago, but it was changed so you had to first enter an invoice. Now it is changed back, whether intentionally or accidentally, I do not know. But the reversion to the original behavior is welcome, because it allows the choice to be made when a business is first being set up, rather than after accounting records are entered.

This is already possible without a Form default. It only requires setting the accounting method in the Summary screen when the business file is first created and setting the accounting method in each each report when first created.

Once one report is created this can be cloned to create another report with the same settings

I had not recently tested the early summary screen behaviour. If it can always be set then no default is required.

To allow a business to be set up for Cash or Accrual accounting that leave Report form defaults for Cash/Accrual accounting.

Sorry, I cannot see the value of having an additional set of form defaults (a separate form default would be required for each different report) just to default one setting in the report definition which can easily be set up when creating each report.

The business has a defined reporting standard to the tax authority. This is a single value. The default should be the set once for all reports from that business.

I do not disagree with this statement. I think that the confusion is coming from the fact that you are using terminology (Form default) that has a specific meaning in Manager. i.e. “Form defaults” in the settings tab.

In fact I have already stated this in this thread:

I don’t really care how Manager ensures cash / accrual defaults to the accounting standard a business elected to report to their tax authority. I only care that it gets it right.

Form defaults was suggested only because it is in the setting tab with other business set up parameters and the thing it actually effects is the default reports setting.

If this behaviour is intended to persist for some time, an alternative would be for Manager to use this setting for the reports default for any new reports. Doing so would achieve the same end result and not require any new settings. It would also implement an idea Lubos had several years ago

I agree that the Manager program should “get it right”, but I would also argue that in this instance Manager is getting it right. It is the user’s lack of attention to detail that is causing the issue.

Having said that, I do think that changes could be made to the program that would assist the user to “get it right”. I suggested these changes earlier in this thread and will repeat them now as it seems that they have not been understood.

"1. At no point does the Summary screen indicate an accounting basis. It should always state the accounting basis that has been selected under the edit tab.

2. Reports do not state an accounting basis, in the header, until a transaction has been entered for either customers or suppliers. Reports should always display the accounting basis that has been selected in the report definition.

3. The default accounting basis for reports is always set to accrual basis. There should be an item in the settings tab where a default accounting method can be set for reports, but not the Summary screen." [There should be an item in the settings tab to select the default accounting method that appears on initial report creation] (added to make the suggestion clearer.)

If the Summary screen and the report headers always displayed the accounting basis that is set in the definition parameters of the summary screen and the created reports, then, even if the user was to distribute a report using the accounting basis that was not desired, it would be clear that the report is not the required type, but not incorrect.

Also, having the accounting basis displayed on every report (that requires it) would go a long way to avoiding an incorrect report type being distributed. Seeing the accounting basis on the report even before it is needed will reinforce the concept to the user and familiarise them with the reporting basis that is used for their business.

I know the philosophy of the developers is to make the Manager program easy to use, especially for users with limited knowledge of accounting, but concepts like cash verses accrual accounting is fundamental to the accounting process.

This is made clear by the fact that tax authorities require businesses to select an accounting basis (or in some cases adhere to an accounting basis) for submission of VAT returns.

Users need to understand, from the outset, that the two methods may produce the same output, but that the output will be different on most occasions.

So, I would argue that introducing this concept right from the start is paramount.

Now that I have finished my rant, I will say that I agree with @Patch and something should be done to improve this part of the program.

Probably worth leading with this in your original post :slight_smile:

Regardless of why someone wants or doesn’t want a feature, it looks like lubos as developer has indicated that he wants the same thing (when it boils down to it, all this topic is asking for is to default the accounting method to cash basis when it is logical to do so – i.e. businesses that run on a cash basis).

EDIT: Looking again at the original post, it seems the request was for more defaults than just accounting method. I must have overlooked that initially.

As mentioned earlier, I agree that defaulting the accounting method to cash basis rather than accrual makes sense for some businesses.

I’m not sold on the benefit of setting other defaults. So this would likely be better not as a ‘Form Default’, but simply as a smart default that the application does itself. Like lubos suggested in his quoted comment.

I don’t get how this proposed change is going to fix the issue detailed by the OP.

The issue arises as a result of these circumstances:

  • The business is set up and for a period of time only cash transactions (receipts, payments and inter account transfer a being entered.
  • there has not been a need at this point for the user to think about setting the accounting basis in the summary screen or the reports they have created. There is also not an awareness of which accounting basis is being used as it does not appear on either the summary screen or any of the reports, and so, all these reports are created with the default of accrual basis.
  • Then there is a need to create a Sales invoice or a Purchase invoice and once this is done it is critical that correct accounting method has been selected.
  • The user distributes a report without noticing the accounting method in the header of the report and it is the accrual basis and not the cash basis.
  • The user is embarrassed by this discrepancy

The changes proposed by @lubos will not make the switch of the default accounting method for new report creation because all of the existing reports have been set by the default default of accrual basis. In any case it is too late because it will not change the existing reports.

I think we agree with this statement

The way of actually achieving this is to allow the user to tell Manager what accounting standard they have elected to use with their tax authority.

At some time it the future the user may choose to notify their tax authority they are going to change from reporting on a cash to an accrual basis. Such as Choosing an accounting method | Australian Taxation Office After following the required process with their tax authority, the user then needs a method of telling Manager of the change going forward.

It all comes down to the possibility of making Manager smarter to provide better accounting standard defaults.

Yes, I agree with the concept of “making Manager smarter”, and I believe that critical analysis that has been presented by users in this thread is going to help the developer to make the appropriate changes to “make Manager smarter” with how defaults work in the program, to help the user to be smarter as well.