Why do the costs on a journal entry show in the net sales column?


I copied this text from the website of the Dutch Tax-administration:

1e Supplies/services taxed at 0% or not taxed at your level Enter the turnover for goods and services supplied by you in the Netherlands at 0% or for which you are not taxed applies to goods and services in the Netherlands to which the 0% rate applies (see table II). Also enter the turnover for which the VAT has been cross-charged to your customer. This is the case if your business is not based in the Netherlands and you supply goods or services within the Netherlands to a business based in the Netherlands.

So line 1e shouldn’t show net difference between sales and purchases. It has to show only the net sales figure.
As I Into the Mirror already stated when it is an inland purchase we only have to report the tax paid, not the purchase value. Exemption to this rule are the products delivered and services rendered to the business coming from within the EU and from outside the EU. The net purchases are reported at line 4a and 4b

@IntoTheMirror the immediate solution to your problem is to effectively create an “Accounts Payable (Suppliers)” subsidiary ledger journal by entering a correcting Purchase invoice as per this:

Which produces this:

Report looks like this:

If you wish to claw back the overpayment of 3.68 to the supplier change the top line amount to 17.50
If the original purchase was a cash purchase create a “sundry” supplier account.
@Hennie putting your EOY WIP journal through the Accounts Payable subsidiary ledger, in this way, I suspect will have the desired effect that you require.

In terms of a permanent solution I support this suggestion by @lubos as it will allow flexibility without having to make a choice as to purchase or sale which would allow too much possibility for error.

@generalegend Thank you, that is the solution for the current situation! You’ve used not exactly my example, so I tested it again.

It’s making a correction JE in the purchase subledger. And indeed, no touching the the sales ledger, because you remain in the purchase ledger, no real actions on the supplier, minimal impact.

Unfortunately it is not when the transaction itself contains two components, as in this case, the Suppliers Purchase Invoice (17.5 + 21%) and the Suppliers Payment (17.50 only). A Journal can correct one but not both components simultaneously.

As @IntoTheMirror discovered, the “incorrect” purchase invoice credited 21.18 against the Supplier while the payment debited 17.50, therefore leaving a balance of 3.68 which became the tax problem within the Journal.

The only way to correct this situation is NOT via a Journal but via an “Adjustment” Purchase Invoice. The “Adjustment” Purchase Invoice would contain two lines, the first line being a reversal (negative numbers) of the error purchase invoice and the second line being the corrected entry. This has three advantages, (1) it fixes the tax, (2) fixes the Suppliers account balance and (3) keeps all transactions as purchases on the tax reports.

For all intensive purposes, it looks like a Journal (one debit and one credit) but it has the ability to correct both the tax and the suppliers balance, WHICH a Journal can’t do.

PS: I don’t know of any tax authority which doesn’t accept an “Adjustment” Purchase Invoice as a valid basis for correcting tax entries.

To do that you would have to:

  • Combine the customer and supplier database

  • Get the user to choose the correct entry from a list containing all customers and all suppliers. I’m not sure this enhances the user interface as when entering the data the user will already know if they are looking for a customer or supplier so would likely prefer the option to display only customers or suppliers.

  • Given companies maybe both customers and suppliers, to select the correct entry the list would need to show if it was a supplier or customer entry.

An alternative is to recognize Manager can mostly determine from context if the transaction pertains to a sale or a purchase. Journal entries are the one exception because they are used to correct errors elsewhere and operate at a lower / more manual user level. Consistent with this, giving the user lower level control would be appropriate. By which I mean, on and only on journal entries allow explicitly specifying if the tax code pertains to a sale or purchase.

A possible user interface is if a tax code is applied to a line in a journal entry, allow specifying if it is a “Sale” or “Purchase”.

Unfortunately it currently can’t be done with a cash transaction, see Goods return (Cash sale/purchase) causes Gross Sales error

How to handle journal entries probably depends on a program design philosophy, or more particularly what journal entries should be used to do in Manager. To illustrate the the two approaches which have been discussed above

Line item purchase sales identification would enable

Journal entry Supplier labeling would enable:
(Selecting type “Receipts” would result in customers being selectable. Analogous to what could be done in Receipts & Payments. Selecting from a combined list of suppliers & customers would achieve similar functionality as described above.)

The advantage of the first approach is it provides direct flexible low level control. The disadvantage is supplier / customer reports will not include JE transactions. Where that functionality was required a JE to a bank account with distribution there would need to be done.

The advantage of the second is transactions could be associated with a customer/supplier. Useful for sole traders performing transactions from a personal account (effectively from retained earnings). It has the disadvantage that line items may relate to different or multiple customers/suppliers so transactions level labeling may not provide sufficient granularity in some use cases.

Personally I think both are reasonable approaches, and both are better than not being able to specify sale/purchases at all.

I suppose a third option is to use the account type to determine sales/purchase tax code component. As sales are posted to income accounts and purchases are posted to expense accounts. I’m not sure what would be optimal when balance sheet posts are made. There may also be use cases when this assumption is not correct.

Edit 2
Thinking about it more, specifying Purchase / Sale per transaction with the option to label the transaction with a customer / supplier (the second option above) is better in my opinion because:

  • It is simpler for most user transactions, maintaining the same mode of operation across invoices / Payment & Receipts / Journal entries

  • It would enable reversal of a transaction by simply entering a transaction identical to the original but with a negative amount/quality. The same procedure applying to invoices / Payment & Receipts / Journal entries.

  • It is more powerful enabling correction / labeling of entries by customer / suppler. Possibly enabling journal entry transactions to also be included in customer / supplier reporting.

  • The only people with cause to use journal entries with line items containing both purchases and sales are likely to be those with an in depth accounting understanding, such as accountants correcting a users records. Someone with those abilities can achieve an arbitrarily complex journal entry by splitting it across two journal entries if requires (all purchase tax codes in one JE, all sales tax codes it the other JE, and items with no tax code to bridge between where appropriate).

Edit 3
On reflection it would be clearer if the transaction level type was “Sale” / “Purchase” not “Payment” / “Receipt” as shown in the screen mock up.

1 Like

I fully support this approach.

Or better still have the field visibility control work in the opposite direction. Only allow entry/specification of a tax codes (or link to a supplier/customer) when the user has specified if it is a sale or purchase. To expand on what this would mean:

For Journal entries

Type Effect
Not set Tax code selector (and supplier/customer selector) not shown.
Set to Sale Tax code amounts are applied to sales totals, increasing the sales totals for credits, decreasing the sales totals for debits.
Set to Purchase Tax code amounts are applied to purchase totals, increasing the purchase totals for debits, decreasing the purchase totals for credits.
Deleted/cleared Tax code selector(and supplier/customer selector) would be hidden, and clicking the update button would delete the tax code / supplier / customer selections.

Having the dependency operating in this direction would:

  • Ensure funds were always unambiguously allocate to the intended component of the tax code, and as a result the totals become a valid measure not an approximation / upper limit.

  • Enable selection of the other party from a supplier or customer menu rather than needing to combine suppliers and customers then select from a list containing both. This facility could also be added at a later date should it’s implementation now be technically demanding.

For compatibility with user selections from older software versions, where tax codes are used but type is not set, the existing behavior would need to be maintained.

For Receipts & Payments entries

Purchase / Sale type

  • For receipts the “Type” should default to “Sale”

  • For Payments the “Type” should default to “Purchase”

  • Where the default is wrong, the user should be able to change a transaction from a sale to purchase or purchase to sale. Typically needed for Goods returned or some foreign exchange adjustments. Transaction type specification ensures negative line items are also recorded accurately such as refunded cost of last item when bulk purchase, some credit card fee adjustments, or refund of deposit when making a final payment.

I’m not convinced that it is necessary to be able to swap between a payment and a receipt after the user had chosen to create a new payment or create a new receipt. Similarly I have trouble identifying a use case to change between a receipt and payment when importing bank statement. The transaction will be a receipt or payment defined by the sign of the amount (however the sale / purchase type may need to be user modified as described above).

I’m less sure of the value in having Receipts or payments which are neither a sale or purchase. If this is valuable then the “Type” would need to support “Null”, “Sale”, or “Purchase” and hide fields as described for Journal Entries, if not the Type would be a “Sale” or “Purchase” for all transactions created in later software versions.

1 Like

Firstly, Manager is currently fully compliant with the Australian GST Tax Act with regards to the reporting of GST Sales and GST Purchases.

Secondly, Manager has always had a policy of requiring OFFICAL documentation to support any taxation programme changes. Therefore @Patch, and this is the third request, if you believe that Manager isn’t compliant with regards to the GST reporting can you PLEASE provide that OFFICIAL documentation to support your position.

For myself, I am not going to be holding my breath as I know such documentation doesn’t exist.
In fact, the graphical charts within the OFFICIAL documentation, supports Manager as it stands.

Even three of the world’s largest financial organisations, Amex, Mastercard & Visa don’t support @patch’s contention that returns / refunds are negative purchases. On your statement the total purchases are exactly that - your total purchases, not your NETT purchases. Any returns / refunds are always included as part of the receipts total - which is the exact same process that Manager currently uses.

This pedantic fixation that somehow Manager needs to change so that one can reconcile P&L Sales / Purchases with reportable GST Sales / Purchases seems to be a crusade by only one user. It is definitely not a requirement of the tax office.

Can I suggest that Manager has far greater feature enhancements to be focussed on rather then tinkling with perfectly working and unbroken components.

Lets say we need to do a journal correction and use Managers tax code facility on JE. To keep it simple we will just move expense account money ie recode a group of purchases. For example

The next day we get further advice and need to reverse the journal entry

We then check the summary screen to make sure this is all fixed (The test business contains only these two journal entries).

Then we check the tax audit report and all is OK there too

So we are very happy our accounts are back in order.
However at the end of the quarter when we go to submit our tax we discover we need to report a surprising volume of sales and purchases

What is happening is Manager accurately maintains the difference between sales and purchases so “Tax liability” (which is the difference between the sales & purchases) is correct. However Manager often does not know if a transactions is a Sale or Purchase so it has to guess. As a result in the tax summary report, all of the reported Sales and all of the reported purchases data is just a guess and mostly wrong.

To avoid reporting false data to their tax authority, the user needs to have an in depth knowledge of what causes Manager to falsify it’s reports. Given what is reasonable for most users to understand about Managers bugs that means

  • Do not ever used tax codes on journal entries

  • Use cash sales with real caution as they will sometimes corrupt your reportable sales & purchases.

  • Use invoices where ever possible including to simulate journal entries



In the context of Managers current behavior, not using JE is sensible however that is mostly because tax codes on JE corrupt Managers tax reporting.

I had also assumed Manager used the receipt / Payment to identify Sales / Purchased however it uses the line item credit / debit so will produce the same error as a JE. Illustrated here for goods returns but the same error occurs with any negative line item in a sales or purchase transaction.

That is because most users assume an accounting program would produce accurate taxation data not just guess, I know I did.

@IntoTheMirror and @Hennie thank you for highlighting what Manager was actually doing. I had assumed Manager was not guessing how accounting data should be reported so corrupting it’s taxation data.

@jhoney Lubos actually summarized what is happening very well on his post above the implications however are rather disturbing.

An accounting program which produces false taxation data when used as it appears to be intended, has a critical bug. Optionally producing accurate data for submission to your tax authority is not just a idea for later.


But that report is for 1/1/1 until 29/9/19…2018+ years!

he is using a test business account with only these transactions. the dates (in this situation) are irrelevant (unless you meant a smiley instead of an exclamation point, sarcasm and humour are lost in text form)

Yeah. my bad, the edit didn’t post. :man_shrugging:
Just thought I’d point out that the report dates didn’t match up with the summary dates. :upside_down_face::upside_down_face:
Smileys worked then?

1 Like

Thank you for excellently articulating a problem I have with manager.

My use case, I use (a part of) the tax summary report for reporting income to our landlord (contractual requirement), however I often appear to have income where it was the return of a purchase*. Because it is usually of a minor nature and doesn’t affect the grand scheme of things, I can largely ignore it.

However, it would be nice if it was recorded/reported correctly.

* I’ve re-created this in a test business, and this is the scenario I have purchased $100 worth of something, I paid for it the next day and returned it a while later. The whole thing appears as “Net Sales” and “Net Purchases” in the tax summary. This COULD be a potential problem if the values were more significant, but they aren’t.

secondary note: I am not using journal entries, all my data entry is entered directly into invoices and like fields.

I feel like there would be a way to get this recorded so that it doesn’t happen.

I have managed to do it now, but this has been as a result of me sitting here plugging away at it, I’m not sure if it would stand to scrutiny, I think it would.

I was about to NOT post it here as it is kind of off topic, however, it’s on point that net sales/purchases appear and I need a way to make them NOT appear, this is how I dealt with it (although I am not about to go through and re-apply this to 3 years of entries):

I have a supplier with one invoice:

This is the invoice:

The fix

Create a debit note and receive a payment:

In the end, the purchase invoice balances:

And the tax audit and summary now post the correct values:

Without that debit note, no amount of juggling the values (that I could find) would get both reports correct.

Lesson (for me):

Don’t return an item without a debit note (in manager).

Perhaps there is a way to do the same for journal entries?

No, Manager makes exactly the same tax guess for all line items independent if the line is done within a journal entry, within a receipt or within a payment.

The only way to stop Manager guessing how to do the bookkeeping is to enter all transaction via an invoice, credit note, or debit note. So the only way of using tax codes in journal entries is to not use journal entries and instead put the journal entry content in an invoice, credit note, or debit note. A rather cryptic way of using the program.

When the amounts are large everyone can spot the problem. When the amounts are small we rely on the software to get it right. I do have a problem with an accounting program which makes bookkeeping errors.

Fortunately Manager could be updated to ensure this error never occurs, so hopefully Lubos will fix it, as I would like to recommend the software to others but can’t with it’s current behavior.

Unless your lease agreement specifically requires you to share the Manager Tax Summary with your landlord, I would recommend reporting income with an ordinary P&L statement. That would be a much more common practice and easier for the landlord to understand. I suspect that is what a landlord would expect.

I use the tax summary because it provides the least information absolutely required by the landlord (it’s just the left/income side of it). The P&L statement provided to much info and not best aligned for my use case (but I will investigate again once I get the chance). Thanks

The latest version (21.1.54) allows to categorize journal entry whether it’s a sale / sale adjustment or purchase / purchase adjustment.

When you select Tax Code on journal entry, the following option will be shown


Not quite sure about the wording for this UI element (maybe it will grow on me) but the basic principle is that all the transaction types have now implicit or explicit ability to determine whether they represent sale or purchase for tax purposes.

1 Like

Could the receipts and payments use something like this instead of the current solution to select customers or suppliers.

Absolutely not. Payments and Receipts works perfectly as it is now. I don’t want a complicated sale or sale adjustment terminology creeping in. Choosing whether they are a customer or supplier addresses all the issues around tax and reverse transactions. So why change it.

The only enhancement I would like in receipts & payments is

  • when a user selects Payee as “Customer” or “Supplier” or “Other”
  • then Manager should immediately respect that choice and not wait for entry of a specific customer, supplier, or others name

By which I mean

  • Line item customer/supplier should only be shown if “Other” is selected as Payee type
  • GST / VAT should be assigned to sales / purchase base on amount sign it Payee type is “Other” . However if the user has set Payee type to “Customer” then for tax purposes line items effect Sales totals, and if the payee type has been set by the user to “Supplier”, then line items should effect purchase sales totals.

Showing a gray “S” or “P” with the tax code to indicate sale or purchase would be an nice addition.

Looks like the latest version does not allow supplier or customer to be assigned to line items throughout Manager, only to transaction. IMO that will probably result in a simpler & cleaner interface in the long term as other things are also required for invoices with multiple legal parties such as showing tax identification of all parties on the invoice. And if it the functionality is required for cash transactions then it is also required for invoiced transactions.

It also unifies the behaviour of Sales invoices, purchase invoices, Receipts, payments, credit notes, debit notes (and journal entries) as all are two party transactions with line items for each transaction applying to only sales or purchase totals. The only exception is Receipts / payments of type “Other” where sign of amount / credit / debit is used.

Edit 2
The down side is a single journal entry can no longer be used to describe a transaction with both sale and purchase tax components, such as a pure barter transaction.

Entering such a transaction on Manager requires

  • Splitting it over 2 transaction (eg invoice for at least one of the components)
  • Zero net value payment / receipt of Payee / payer type “Other”

The change also means

  • Arbitrary complex tax correction journal entries (with sales & purchase corrections) will need to be spread over 2 journal entries.
  • Journal entries can no longer move items / money / tax between customers / suppliers. I’m less sure of the use case for this so removing the capability maybe a good thing.

The net effect for me is probably easier for most of my transaction (other than having to correct old data). One barter transaction I will have to re-enter.
Others maybe effected differently.

Edit 3
For my pure barter transaction use case the best solution for me is a balancing receipt and payment. Reasons:

  • allows separation of sales & purchase components of the transaction.
  • list with all other similar transactions in the same format.
  • normal supplier/ purchases reports