When creating a journal entry, the system must not allow data entry in both the debit and credit fields on the same row. In other words, if a value is entered in the debit field, the credit field must remain blank, and vice versa.
That would indeed be convenient. But why restrict to journal entries? Same would work for payments, receipts and inter account transfers, I think.
Hello @contabl2006,
I know there are many technical accounting conventions dating back to the paper ledgers. Many of these conventions have been made obsolete by modern day computing.
Whenever I am faced with any of these technical conventions, I always ask these questions:
- What problem did this solve?
- Is this still a problem today?
- Am I legally obliged to continue to do so?
Accounting is precise — software makes it easier, but not without minimum fundamentals.
In Manager, click the Transaction Journal button at the bottom right of any transaction. You will see the exact double-entry journal from your accounting textbook. That journal is the single source of truth of your accounts.
The UI forms (invoices, receipts, payments) handle daily work with minimal accounting knowledge — if Manager is set up correctly for the business.
Journal Entries, Chart of Accounts, Control Accounts, and Special Accounts are for the expert layer — intentionally flexible, just like double-entry accounting itself.
Every business will eventually have entries that need real accounting knowledge: write-offs, provisions, depreciation, intercompany adjustments.
From my experience helping businesses design their Manager setup — validation rules are useful for beginners, but they should never restrict the full power of double-entry accounting for advanced users.
Manager combines two precise disciplines: accounting logic + relational database design.
That combination is what makes it one of the strongest financial architectures available for SMEs today. ![]()
Name one!!
If I may respectfully refer you to the OP. There could be nothing wrong with it as a request, however, since no other user has faced a problem as a result of this over the course of more than a decade since Manager started, this only suggests that the problem this convention used is no longer relevant.
I have been placing credits and debits on the same line for the better part of two decades now
Another example is ledger subtotals c/f and b/f which is rendered obsolete by modern databases.
I will assume the risk veering off a little, but I think the benefits of analogy are too valuable to ignore, so please bare with me:
A man asked his wife why she was cutting off fish tails before frying and she said that’s the right way that her mother always used to do and she never bothered to learn why.
Later, when she asked her mom, her mom told her that she only did this because her frying pan was too small to fry a whole fish.
The takeaway here is that it’s always better to do a cost-benefit analysis before introducing changes.
In the case of the fish, the cost was trivial to solve a non existent problem.
However, in the case of Manager, the developer has to spend valuable development time and risk other users suffering unexpected outcome due to change in convention.
I don’t pretend to know why the OP was ever in place, but given what’s at stake here, it’s only wise to ask why:
-
If this is a regulation somewhere, then that would trump all other arguments, and some non-intrusive fix could be taken to prevent future occurance and leave retrospective corrections up to the user.
-
If on the other hand, the root problem is more fundamental, more extreme measures could be justified.
-
Otherwise, this could well be something to help reduce the number of manual calculations during validation and audit. Which isn’t really applicable nowadays.
I was confusing conventions with principles. Accounting principles have not changed, but you are correct, computer processing has changed some of the conventions and methods of representing the principles. Often to detriment of user’s knowledge and understanding of the process of producing output required by the principles.
Some accountants that I know, when explaining a complex situation will represent it in T ledger style to make it easier to understand.