I propose using unsigned amounts in transactions, along with GnuCash-like keywords to specify the sign (Debit/Credit). For instance, one might enter:
2024-03-17 "Buy a book" Expenses:Entertainment 8.95 USD expense Liabilities:CreditCard 8.95 USD charge
I am not a fan in general, getting accustomed to double-entry bookkeeping is not a nuisance, but a worthy goal.
But if we want to go towards the “it is intuitive road”, what would be the signs of a paycheque transaction?
2024-03-17 forthnightly wage
Revenue:Job —80¤ revenue
Assets:Bank —80¤ deposit
For laymen, revenue with a minus sign before it is not intuitive.
I think the OP is proposing just this:
2024-03-17 fortnightly wage
Revenue:Job 80 revenue
Assets:Bank 80 deposit
Ie don’t write signs at all, replace them with keywords.
And then you might say the keyword is redundant or potentially conflicting with the account, so why not omit both sign and keyword and figure out the directionality from the account’s name/type and/or a transaction type.
Then not a fan of those specific keywords. 
You add a car to your assets, do you “deposit” it?
so why not omit both sign and keyword and figure out the directionality from the account’s name/type and/or a transaction type.
This makes more sense, but still somewhat tricky to figure out correctly for non-trivial transactions.
OP’s solution, to me, solves nothing.
2024-01-01 Yet another transaction
Expense 300 debit
Cash 300 credit
What about this? I think one of the reasons PTA feels unintuitive(at least for me) is that it adds another unintuitive element(+ for spending? - for earning?) to something that is pretty much unintuitive on its own which is accounting. Assets belong in debit not because it’s added or going up but it is where they belong, same thing with liabilities. Using (+/-) kinda ignores that point but
Using debit/credit just like corporate accountant would do removes extra layer of unintuitiveness.
1 Like
I think that’s relative… what’s intuitive is not the same for everyone. For me + for going to, - for coming from was intuitive (and with that as foundation my understanding of debit and credit improved).
It would be relatively easy and low impact for PTA tools to support dr/debit and cr/credit keywords as synonyms for + and - in journal entries, like:
2024-01-01
expenses:food debit $50
assets:cash credit $50
2024-01-01
expenses:food dr $50
assets:cash cr $50
Maybe some people would prefer that notation, though perhaps a minority given PTA’s techie bias. It would certainly help underline that sign and debit/credit are equivalent in PTA.
Using that notation in reports is another step and also possible. Ledger can do it with --dc (showing the numbers at least, without the keywords). Here’s what that looks like, for the record:
~/src/hledger$ ledger -f examples/sample.journal bal --flat -E
0 assets:bank:checking
$1 assets:bank:saving
$-2 assets:cash
$1 expenses:food
$1 expenses:supplies
$-1 income:gifts
$-1 income:salary
$1 liabilities:debts
--------------------
0
~/src/hledger$ ledger -f examples/sample.journal bal --flat -E --dc
$2 $2 0 assets:bank:checking
$1 0 $1 assets:bank:saving
0 $2 $-2 assets:cash
$1 0 $1 expenses:food
$1 0 $1 expenses:supplies
0 $1 $-1 income:gifts
0 $1 $-1 income:salary
$1 0 $1 liabilities:debts
--------------------------------------------
$6 $6 0
(The columns are sum of debits, sum of credits, and their total.)
I am not a fan of this proposal, mostly because “debit” and “credit” over time accumulated lots of different meanings, and by adopting “debit/credit” we don’t adopt just one preferred meaning, we pull in all of them, implicitly. Also, “debit” and “credit” could be both a noun and a verb, unlike, say “positive/negative” or “add/subtract”.
I agree that in some cases it looks nice : “I debit my debit card to buy some ice cream”.
But tomorrow I am buying a car: “I debit my credit card to buy a car”. Why am I not crediting my credit card instead? 
Because two instances of the word “credit” have different meanings.
I agree with one point: if you started your journey into accounting with “debit/credit”, and they are firmly internalized into your mental model, then “+/-” might be confusing and require extra mental effort. For a while, at least.
However, if one is not a chartered accountant already (one that natively speaks English to boot), then it is possible that “debit/credit” is way more confusing. Now, lets bring in all the possibly synonyms (revenue, deposit, charge, rebate, …) and add i18n into the mix (for extra confusion, in some other languages you can use both debit/credit as loan words as well as native equivalents, and sometimes they are not synonims, but actually mean slightly different things) and everything quicky get messy.
+/- is wonderfully neutral in this regard
I can now agree with you with most of the things. I use Arch and Vim and all but I also know accounting way more than I know about computer stuff so I’m clearly biased.
Well, that’s just how accounting is though. But then again, I understand that it can be confusing. I was just trying to make a point that It’d be nicer if it actually has visible resemblance to the real-world case.
I hear that. I think it’s interesting to think about more or differently “intuitive/friendly” presentation and ui options, as is standard in mainstream finance apps, but of course without sacrificing clarity at the base.
And you’re right that “debit” & “credit” are anglocentric, and keywords/uis means i18n issues. “Dr” & “cr” are (a little) better in that regard being short and latin (abbreviations for “debere” and “credere”, it is said, though actually who knows, see wikipedia).
The idea is that different keywords can be used depending on the transaction taking place; my implementation has a table of allowed keywords. When you get a wage payment, then Assets:Bank might get a “deposit”, but if you add a car to your assets, you might just say “increase” or “opening balance”. GnuCash (where I got inspiration for the idea) does something like this too. For instance, a bank account type has columns Deposit/Withdrawal, whereas a cash account type has columns Receive/Spend, even though both are Assets.
1 Like
Discussion is really interesting and there is people with more understanding of accounting and PTA… But IMHO there are two different issues to consider: (1) format of plaint text files of PTA and (2) input/output data according to PTA or classical accounting with credit/debit columns.
Although modifying the format of PTA could provide better integration with classical accounting, i think with correct input tools (cli tools, web based…) and output tools (credit/debit columns for balances, registers…) the text format of PTA is not required to be modified. As we do not need to modify the binary format or xml format of other accounting tools such as Gnucash.