Goods return (Cash sale/purchase) causes Gross Sales error

I would say a reversal, not a cancellation, because you are not deleting the transaction which originally recorded the purchase. But we are down to semantics. There is no point arguing over those.

Indeed is a reversal, not a cancellation (sorry for my bad English), so I edited my post.

As to why Manger users would consider this important

  1. Manager reports Purchases separate to Sales by tax code. If you really believe no jurisdiction requires this then, Manager should just report the difference.

  2. The tax summary report is the principle report used to submit VAT/GST reports to the taxation department. Almost all have significant penalties for submitting false information.

  3. Manager is principally and accounting program. It can help in other areas as well, but accounting is it’s foundation. If it can not produce accurate accounting records for submission to local tax authorities, it has a core requirement defect.

  4. The behavior identified is not new. As a consequence it implies many Manager users have been submitting false records to their tax departments for a long time. A challenging thought and not good for Manger sales.

As to is there an issue at all.
Even before we address what effect individual physical transactions should have on reported sales or purchase, consider the process at a more abstract level.

  1. A physical business purchases & sells, goods & services

  2. An accounting system is used to record the business transactions. The accounting system uses accounting conventions consistent with local legislation.

  3. Taxation data is submitted to local tax authorities based on the physical trade the business has done and the accounting conventions adopted.

The critical point of the above description is for a given physical trade and accounting conventions the reported taxation information is fixed number not a range of values. There is a right answer and other numbers are false.

Now consider all 4 examples listed above

  1. Each involves a fixed activity on the shop floor, with fixed goods and services changing hands, and fixed physical documentation from each of my suppliers.

  2. In each my book keeper could enter, apparently validly in Manager as shown in the “Payments” edit screens above (and generate reportable sales in Manger).

  3. In each my book keeper could enter, apparently validly via invoices in Manger and generate no reportable sales in Manager.

  4. In each case Manger is reporting a different reportable tax for the same physical transaction and adopted accounting convention.

If accounting conventions really dictate that the sales generated when entered these transactions as a Manager “Payment” is correct then Manger has a bug in how it calculates sales when entering these transactions via an invoice (which I don’t think anyone really believes). My point is for a given physical trade and adopted accounting conventions there is a right answer, other numbers generated by my book keeper and software are false.

Finally we can look at the details of all 4 physical transactions described.

Goods return: Some suppliers have a sales policy which includes a goods return option. The return option requires a valid sales receipt (which is edited when the goods are returned), is valid for a limited duration, is priced at the prior sale price (some with a restock deduction) not the suppliers normal wholesale purchase cost, and when I return (?sell) the goods I do so without providing a warranty. In summary the goods return process is contractually not the same as a sale. It is processed correctly in Manager if a Manager invoice (or Manager Debit note) is used and incorrectly if entered directly in Manager via the “Receipts & Payment” tab (without an invoice or debit note).

Deposit deduction: When final payment is entered without an invoice Manger treats deduction of the prior deposit as an additional sale. Clearly no goods or services are delivered for the “sale”, it is purely a correction to the current “Payment” for a prior payment towards the documented goods & services. It is processed correctly in Manager if an invoice is entered first in Manager and incorrectly if entered directly in Manager via the “Receipts & Payment” tab (without an invoice).

Bulk purchase discounts: Some suppliers offer a discount if a particular threshold amount is purchase at one time. Deducting the cost of the last item or some other dollar amount. In no case is the purchaser providing any goods or service, they are only receiving a deduction in cost on the current purchase. It is processed correctly in Manager if an invoice is entered first in Manager and incorrectly if entered directly in Manager via the “Receipts & Payment” tab (without an invoice).

Some financing adjustments: depending on the details of the payment used an adjustment some times negative maybe required for exchange rate variations or credit card fees. Typically they are an integral part of the financial transaction (zero without the underlying transaction occurring). When negative they do not suddenly become a new income for the business instead they remain and adjustment to the underlying (in the illustrated case) purchase. It is processed correctly in Manager if an invoice is entered first in Manager and incorrectly if entered directly in Manager via the “Receipts & Payment” tab (without an invoice).

In Summary

  • Manager has a serious bug in how it records taxable goods and services when a Manager invoice is not created which results it corruption of the amount shown in the “Tax summary” report

  • It can be masked by not relying on Managers “Tax summary” or any of the “VAT/GST calculation worksheet” localisation (as they all use the same data). Doing so involves also using 2 custom reports and external calculation. Journal entries need to be individually examined.

  • It can be fixed within Manager but as it has been known about but not fixes for many months, correcting it is not trivial

  • An accounting program which makes accounting errors in tax reports may well be a Marketing problem for the software and difficult to accept for the users who have submitted incorrect taxation data for years, but the solution is to fix it not deny it is a problem.

1 Like

I am going to make one final comment.
The problem with accountants is that they can only see things in accounting terms.
The tax authorities are not accountants, they are tax collectors, although some maybe accountants but its not a prerequisite.

As I have repeatedly stated - when it comes to GST/VAT Tax Sales & Purchase, it is not referring to “accounting” sales and purchases. It is referring to where GST/VAT Tax has been received or paid. In fact it would be clearer (even for accountants) if the authorities actually called it GST/VAT Received and GST/VAT Paid to remove the accounting connotation of sales and purchases.

@patch your deposit deduction example is flawed. Deposits, not being a goods or service, are financial transactions and as such don’t have tax implications. When you deduct a deposit, you don’t also give a tax refund, as no tax code should have been applied to the receipt of the deposit.

You repeatedly assert that using Manager “results in false accounting records”.
If that is genuinely the case, then WHY are you using Manager.

It’s noted that even though you have been requested several times to provide official documentation to support your assertions that Manager is flawed - you have repeatedly failed to provide such proof.

Writing paragraphs of self fulfilling verbiage doesn’t equate to Manger functioning unlawfully.

1 Like

I made the assumption Manager was an accounting program and would take program errors which result in false accounting records as a serious issue which would be addressed with an appropriate priority.

I did not make the assumption Manager was bug free. All programs contain bugs. Coding and program design bugs increase as program complexity and development rate increase. Manager is a complex rapidly developing program, as such a high frequency of bug discovery is to be expected.

As to details of the specific examples, all contain negative line items in which Manager’s error is to swap between customer and supplier. In the case of the deposit an identical tax code must be applied to the required tax code used when the deposit was accepted. The actual tax code applicable varies with jurisdiction but in all jurisdiction it is an negative valued purchase line item not swapped to a positive valued sale line item. It is processed correctly in Manager if an invoice is entered first in Manager and incorrectly if entered directly in Manager via the “Receipts & Payment” tab (without an invoice).

If that was the case (false accounting records) then Manager would address it with priority.
However, nothing that you have illustrated has proven that Manager is creating false accounting records. What your commentary has shown is that you don’t understand or can’t distinguish the difference between Manager the Accounting Software and the Add-ons used for external purposes.

But first lets clearly debunk your false and misleading claim regarding the false accounting records.
Using your own data (per below), lets process it as both a Sales Invoice and Cash Receipt.

Now if one drills down on the Tax Payable account you will clearly observe that both accounting transactions have been processed in EXACTLY the same manner.

Therefore, where within the Manager Accounting Software are these programme errors occurring which are generating “YOUR” claimed false accounting records ???

Your original issue has nothing to do with Manager the Accounting Software but with the Add-on feature of GST taxation reporting, which is external of the Accounting Software.

Now to simplify your original issue without all the bloated verbiage, you contend that the GST taxation reporting sub-totals being generated were incorrectly accumulating the source data. Furthermore, you hold this view because of the accounting processing of contra transactions.

However, what you haven’t grasped even though it been explained several times is that GST taxation reporting is NOT accounting reporting. Manager’s generated sub-totals complies with the requirements of GST taxation reporting.

To illustrate this with your phone purchase / refund example. Whilst the two transactions may result in an accounting contra, for GST taxation reporting they are not a contra but two stand alone transactions. Whenever you receive GST then it is a GST Sale, regardless of the GST being received via a refund or selling to a third party. Any GST received can’t be a negative GST Purchase.

The basis behind the GST transaction is not relevant to the tax authorities. Their sole focus is the collection of GST. This is different to Income Tax reporting.

As always, if you can provide official documentation to the contrary then please submit it.
It is noted that all previous requests have resulted in your failure to provide such.
You need to note that your personal perspective alone is not going to have any validity.


It appears we are talking about different things. The above post describes how to investigate a coding bug. Manager does not have a coding bug, it behaves as designed. It has a design bug.

It appears there is a variety of opinions on what defines a taxable sale/purchase (and standards accounting software must achieve).

Option 1: Every credit line item must be a sale for tax reporting. Every debit line item must be a purchase for tax reporting.

This interpretation is hard coded into all Journal entry, Receipt and payment so these transactions are consistent with this interpretation. However if this convention is correct then the encoding of debit notes, credit notes, and negative amount line items in invoices, are all incorrect. As a result sales & purchase totals reported in Manager are lower than this accounting convention dictates.

Option 2: A taxable sale or purchase is defined by jurisdiction specific requirement on the goods / service provided, supplier obligations, and purchaser obligations.

This interpretation is hard coded into all invoices, credit notes and debit notes in Manager so are consistent with this interpretation. However if this convention is correct, then all negative line items in sale and purchase “cash” transaction and about half journal entry line items, are all incorrect. As a result sales and purchase totals reported in Managers are higher than this accounting convention dictates.

Most jurisdictions have specific invoice documentation requirements to enable claiming or when charging / collecting taxed supplies. When making a taxed sale, an invoice must be issued by the seller to the purchaser (and include jurisdiction specific requirements such as VAT amount and type, sales total, time limit from sale to invoice delivery). Conversely when making a purchase, to enable business to legally claim a tax credit, an invoice from the seller is required (meeting jurisdiction specific requirements including purchase total, VAT amount, number of years the invoice must be kept to meet tax department auditing requirements). Importantly a businesses documentation requirements for a sale are not the same as the documentation requirements for a purchase. Transactions entered in Manager via an invoice, credit or debit note require the same documentation for all line items (all line items in a transaction are either a sale or purchase) so are consistent with these documentation requirements. Transactions entered in Manager via “cash” sale/purchase or journal entry allocate sale/purchase per line item, implying a documentation requirement not supported by any POS system, customer or supplier.

In jurisdictions where this interpretation of sale/purchase applies, a positive tax sale line item is not equivalent to a negative purchase line item. The reportable total sale, total purchases and documentation requirements are different.

Option 3: Accounting convention can be altered on a per transaction basis at the book keepers discretion

If this option is correct, both of the above options could be used in a business during a taxation reporting period. This is the current way Manager behaves.

For it to be correct a jurisdictions taxation authority would need to:

  • Accept either interpretation of sale / purchase and allow changing between reporting standards many times within a reporting period. Or
  • Require accurate reporting of the net tax liability but have no accuracy requirement when submitting total taxed sales or total taxed purchases. Or
  • Have no invoice issuing requirements for sales, or invoice retention requirements for purchases.

Official documentation

Changing between accounting standards is permitted where both methods are permitted by the taxation authority for that business for example between accrual vs cash basis accounting. However doing so is only permitted between accounting period, with the consent of the taxation authority, and reporting of any transactions spanning the reporting periods Choosing an accounting method | Australian Taxation Office

Accuracy of submitted amounts : all jurisdiction requiring reporting of total sale or total purchases as well as net tax liability; require the user to declare all amounts are accurate, not just the net tax liability. For example in Australia when submitting your business activity statement the user must sign

Definition of a tax sale / purchase : despite looking I could find no jurisdictions where a sale / purchase is defined as required by option 1 above. Every jurisdiction I have examined require option 2 above. For example in Australia a Taxable sale GST definitions | Australian Taxation Office requires

And you must provide a “Tax invoice” within 28 days Tax invoices | Australian Taxation Office

Neither of these conditions are met when returning goods, getting a discount on a purchase, deducting a previously paid deposit or any other example of a negative line item entered in a “Cash” purchase.

For negative line items in sales when a POS system other than Manager is used (and Manager is not used to generate invoices) similar issues arise. When I give a customer a refund, the customer never supplies a tax invoice, nor to they accept an in-store credit, they always require a cash refund. So if I was to consider that transaction in isolation as my business purchasing something from the customer, and without receiving or retaining a tax invoice for 5 years, I can not legally claim a tax credit. The same issue arises with all other negative line items in Manager “Cash” sales.

In support of the above interpretation, the ATO explicitly states when a discount is used the discount must be subtracted from the price BAS and GST tips | Australian Taxation Office

In the UK returns are explicitly required to be entered as negative sales amounts [Withdrawn] How to report EU sales made on or before 31 December 2020 for VAT - GOV.UK

Penalties for submitting false taxation information : All jurisdictions have significant penalties for submitting false information. Taxation authorities accept submitted information on face value (so not being prosecuted is not evident prior submission were correct) and instead use some form of auditing to check and achieve compliance. Having inadequate accounting practices is explicitly penalised in Australia

If NGSoftware considers submission of error free taxation information a secondary add-on feature then I have seriously misjudges the company and their product.

Not every credit line items must be a sale . Similarly not every debit line item must be a purchase . Coding forcing this requirement is a bug. In a business which is running well there is a statistical association, so the bug produces numbers which look superficially correct however that makes the bug worse as users are less likely to detect and correct it.

Give the time Manager has had this accounting error I would be surprised if in was fixed in the near term. For those who are concerned about compliance with record keeping requirements when submitting financial records to the taxation department, the following is a summary of how to work around Managers current limitations.

The easiest way to do this with cash transaction is use “Receipt” as a flag to indicate the transaction is a sale, and use “Payment” as flag to indicate the the cash transaction is purchase. In practice this will already the case for most cash sales and purchases.

The steps are:

  1. Find cash sales not entered as receipts and cash purchases not entered as payments (via a custom report or drilling down on expense/income accounts and sorting by transaction type)

  2. Find negative line items in cash purchases and Negative line items in cash sales (via a custom report).

  3. Calculate a corrected “Tax Summary” report and use that to calculated GST reporting data

In more detail.

Cash purchases not entered as payments can be found manually by drilling down from the summary screen on each expense account, clicking on the “Transaction” heading to sort by it then click again to reverse the sort order (and look at the other end of the list).

Similarly for cash sales, drill down on each income account, click on “Transaction” heading twice and confirm all are “Receipts”.

This process can be automated by marking all expense accounts, such as by appending a period character “.” to the end of each account name then using this custom report to find all negative amount expenses ie Expense refund which should be negative Payments.

Similarly all income accounts can be marked by appending a character such as semi colon “;” to the account name. The following custom report can then be used to find all negative amount sales ie Sales refunds which should all be negative Receipts

After this has been done all transaction have a flag indicating to Manger if the user has the documentation required to by the tax department to be retained for a Sale or the documentation required to by the tax department to be retained for a purchase. These flags can then be used to find any line items Manager does not report consistent with the users obligations.

Negative line items in cash purchases are displayed by this custom report. Manager incorrectly assumes they are positive value sales so all must be subtracted from sales (to correct Managers error) then subtracted from purchases (to implement what the user entered)

Similarly negative line items in cash sales are displayed by this custom report. Manager incorrectly assumes they are positive value purchased so all must be subtracted from purchases (to correct Managers error) then subtracted from sales (to implement what the user entered)

Finally the Tax Summary" report can be updated, from which the GST reporting totals can be calculated. This is most easily done in a spreadsheet as Mangers “GST Calculation Worksheet” localisation can not be used.

Let me jump in into the conversation.
@Patch @Patch @Tut @Hennie I think the current System Manager is using to report Tax liability is alright.

I think the only thing we need now is more clarity as not every transaction in the tax report is a Purchase or a Sale transaction.

If I return an item I bought for my money, I have not made a sale or generated income, I have cancelled a previous purchase, this is reported as such in the general ledger, I know.

Imagine if this reversal happened in the next year and that was the only transaction that happened in that new year and the tax report classifies it as a sale. That may create confusion for the reader of the report until they drill down and see the details. I strongly believe reporting a reversal of a purchase transaction as a sales transaction in the report may create confusion for users, especially for people who are new to accounting.

@lubos We only need a small clarification in the report in my opinion to resolve this issue. I suggest that:

Net Purchases Heading should be reported as ‘Net Input’

Tax on Purchases Heading should be reported as ‘Net deductible input tax’ or just Net Deductible Input

Total on Purchases should be reported as Total Input

Net Sales Heading on the report should be reported as ‘Net Output’

Tax on Sales Heading should be reported as ‘Net Output Tax’

Total Sales Heading Should be reported as ‘Total Output’

Lastly, it would clarify things if the Tax transactions report shows the titles of transactions e.g. Sales Invoice, Purchase Invoice, Credit notes, Journals, etc. If the user uses a Custom Title, the report must display the custom title. E.g. a user may change the title from Payment to “Cash sales reversal”, the tax report and other reports must capture and show this detail in all the report for clarity.

Credit notes and Debit notes are to be linked to a source invoice, receipt and payments however cannot be linked to a source payment and receipts because accounts are not opened for cash customers, treatment of cash sales and cash purchases reversal can never be the same as with invoices.

This is a purely semantic debate. No, you may not have sold an item in your inventory to a customer as such a transaction is ordinarily understood. But you delivered goods to someone and received compensation. If I told you only of the circumstances in the previous sentence, you would most likely agree that I had made a sale. I still do not see why this subject is generating so much passion.

The same discussion over column headings on this report was undertaken several years ago. The conclusion then was that no matter what headings were in place, some users would be confused because of local language usage or details of their accounting practices or tax policies. The developer settled on the current terminology, fully understanding the potential confusion.

I think this would potentially cause more trouble. The current approach tells you without doubt which transaction type from what tab (in the program’s terminology) the transaction is from. When users insert custom titles, there is no mechanism for standardization. And who would remember whether a “cash sales reversal” entered a year previously came from a payment or a sales invoice with negative prices?

On the contrary, receipts and payments can definitely be linked to customers and suppliers at the line-item level. After Accounts receivalbe or Accounts payable is selected as the account and the customer/supplier name is chosen, an invoice number can be selected.

I meant it cannot be linked with customers and suppliers in the manner credit and debit notes link up with their source invoices.

I don’t believe this, more details always reduce troubles. If a ‘Receipt’ for cash sales could be distinguished from ‘Receipt for the return of goods’, it would help make things clearer. Not to deviate from this topic but here is another reason this would be good, if I send a sales invoice document with the custom title “School Fees Bill” to my customer, wouldn’t it be right to see the title “School Fees Bill” appearing on the customer statement for easy identification?

It an interesting discussion.

I disagree. A receipt or payment entered as described directly reduces the balance due of the corresponding invoice and shows up in the mini-statement on the invoice exactly the same way a debit or credit note does. Likewise, it will show up on a customer/supplier statement (transaction type) the same way.

This is true if there is an account for the customer. You cannot link cash sales (Receipt) to a cash refund (Payment). The reversal transaction will be treated as a stand-alone transaction. I was only using it to explain to @Patch why he shouldn’t expect the workflow of Credit sales and Credit purchase and their effect on the tax report to be the same as Cash transactions.

OK. Now I understand your purpose, @Abeiku.

By the requirements/definitions specified in existing tax legislation, and what customers actually do when returning goods, this is almost alway the case in practice.

No, Manager makes an accounting error resulting in user supplying false information to the tax department. The error is such that it is difficult for users to detect that is occurring, so worse than an overt error. Most small business only introduced accounting software because they need to submit regular business activity statements (GST summary), so currently Manager is not actually fit for purpose.

A valid sale for GST purposes is defined by taxation legislation via multiple specific requirement. See (and the detailed explanation which follows it):

I am not aware of any jurisdiction where their taxation legislation allows:

This accounting error Manager makes is much broader than just cash returns but getting back @Abeiku example
Abeiku buys an item, say a face mask and some gloves from another person say JohnsChemist. During this transaction as legally required

  • John is registered or required to be registered for GST and:
  • John makes the sale for payment
  • John make the sale in the course or furtherance of a business (enterprise) John carry on
  • the sale is 'connected with Australia
  • John issues a valid “Tax invoice”

As a customer Abeiku, can claim a GST credit for the face mask provided

  • Abeiku retains the tax invoice for 5 years
  • Abeiku buys the face mask for use in Abeiku’s normal business

The important feature to note is no reference is made to accounting software used or if the book keeper enters the transaction as a cash sale/purchase in Manger or enters and invoice in Manager.

Now Abeiku takes the face mask to work, finds he got the wrong sort or they are faulty. He takes the possibly faulty face mask back to JohnsChemist and demands a full cash refund. John cares about the quality of service he offers so complies.

The GST reporting implications of this second transaction depend on what is actually documented and the normal business of Abeiku and John. In almost all cases the chemist John (the original supplier) will edit his original “Tax invoice” to show a sale not including the face masks (leaving just the gloves). This legally defines the transaction as return and results in a negative adjustment to Abeiku purchases and Johns sales. As explicitly stated in British VAT law [Withdrawn] How to report EU sales made on or before 31 December 2020 for VAT - GOV.UK

Manager accurately documents the transaction if Abeiku’s book keeper enters a purchase invoice in Manger and Johns book keeper enters a sales invoice in his Manager business.
If Abeiku’s book keeper does not enter an invoice in Manager, Manager will report the face mask return as a new sale (a different amount reported to the tax department because of a decision Abeiku’s book keeper made). For Abeiku to legally claim the GST on the original face mask purchase he needs a valid tax invoice (which he no longer has). Abeiku is also in breach of his requirements as a “Seller” as

  • Abeiku did not provide a valid tax invoice within 28 days on return of the face mask to John.
  • Abeiku did not make the sale in the course or furtherance of a business (enterprise) Abeiku carrys on

And from Johns perspective

  • Johns has not received Tax invoice for the “purchase”/return of the face mask so can’t retain it for 5 years
  • John has not bought the possibly faulty face mask at full retail price for use in John’s normal business (his business would go broke if that was his supply chain), he has accepted a return.

@Tut you are correct a very similar transaction could be a new sale but for that to be the case different documentation is required and Abeiku needs to have a different normal business. For example, suppose Abeiku normal business was a commodity trader. He may have traveled around buying all gloves and face mask from all chemists (including Johns). He retained them in his warehouse then when a later supply shortage occurred he sells them back to various outlets (including John’s) for an inflated price. The second sale would then be a new independent transaction. Abeiku would issue a valid tax invoice to John for products and service provided as part of Abeiku’s normal business.

The important message to take away from this discussion is

Manager can not tell for cash transactions if the transaction pertains to a sale of purchase as defined by each jurisdictions tax laws. Which is why accounting software must rely in the user specifying if it is a sale or purchase.

I disagree with this @Patch Manager shows all that qualifies to be Input tax in the purchases side and same for Output in the sales side. There is nothing wrong with the report except for the headings for the tables which could be renamed to show the columns do not contain only pure sales and purchases, but also everything that qualifies to be input or output tax.

For a credit transaction, the invoices get adjusted with credit notes/debit notes. So that is why invoices which were adjusted with credit and debit notes get withdrawn completely from the tax summary (even though it still shows in tax transactions as it should).

The tax summary shows Completed Transactions only. A completed transaction here is either a Cash Transaction or Invoice Transaction plus/minus credit/debit note adjustments. A debit note or a credit note in itself is technically used to adjust the payable or receivable of a linked/targeted original invoice, it same in Quickbooks. This is why a Debit note in your original case (assuming it was a credit transaction) would not post a sale to net off the purchase for a zero tax liability but reduce/remove the purchase. It is right because the debit note here would adjust the original invoice amount to Zero (No purchases) effectively re-completing the transaction with a zero balance.

The blood :drop_of_blood: flow of every organization is cash. Every Cash exchange is a separate completed transaction regardless of it being a reversal of an original transaction or not. Therefore, a cash reversal transaction in your first case must be treated separately.
So your output tax must go up with this separate reversal transaction (the return of the phone for your money) to offset the earlier input tax (Also a separate and completed transaction).

I still hold the view that the statement (Tax Summary) is correct but the headings could be altered to make things clearer.

The tax summary as currently produced can not be easily use generate GST submissions because Manager is forced to guess if a line item is a sale or purchase. Where GST offsetting is allowed the net GST owing is correct but in jurisdictions where sales or purchases must be reported this figure is wrong given the Tax department’s definition of a sale and the tax departments definition of a purchase. How it is entered into any account software does not change taxation law requirements.

It is possible to work around Managers accounting bug, but doing so is very inefficient, see

What you have stated is incorrect. Tax Authorities/law focus on Output and Deductible Input Tax. Tax Laws provide for the reversals, bad debts, tax credits etc which are allowed as deductible inputs when calculating tax liability. No one will require a purchase and sales report only Input tax and output tax report.

To claim a GST tax credit specific conditions and documentation is required.
Similar when GST is collected specific documentation must be provided.

When submitting a GST return the user takes responsibility for meet these requirements.
They apply to all GST transaction. The requirements are independent of how the transactions are entered into Manager or any other accounting package.

Manger makes an accounting error. For the same external event and legal requirements it produces different sales (a reported quantity in Australia) and purchase figures depending on how your book keeper apparently validly enters transactions. The sales Manger reports is wrong if any negative line items are used in a “cash” sale or “cash” purchase (ie an invoice is not used in Manager).

That is correct, but that is not what Manager does when the user enter a negative line item in a cash sale or cash purchase. The sales figure reported is not as required by GST law and the users documentation requirements.