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

[d3mad]

@VACUUMDOG

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)

[VACUUMDOG]

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

[d3mad]

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?

[Patch]

@d3mad

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.

[Tut]

@d3mad

I use (a part of) the tax summary report for reporting income to our landlord (contractual requirement),

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.

[d3mad]

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

[lubos]

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.

[Ealfardan]

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

[dalacor]

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.

[Patch]

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.

Edit
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