I’d welcome input from other accountants to review the proposed terminology, over and above the huge amount of work David Cousens has done on the documentation.
Posts https://lists.gnucash.org/pipermail/gnucash-user/2025-November/118164.html * Proposal https://lists.gnucash.org/pipermail/gnucash-user/2025-November/118165.html * Terms "Split" and "Multi-split" usage is inconsistent and ambiguous * Agree with term "entry" for each line https://lists.gnucash.org/pipermail/gnucash-user/2025-November/118193.html * Term "Import Account" is confusing https://lists.gnucash.org/pipermail/gnucash-user/2026-January/119038.html * Directed to revised code https://lists.gnucash.org/pipermail/gnucash-user/2026-January/119041.html * Nice to use accounting terminology * Propose simple/compound import rather than multi-split/multi-line * Support radio button to select option https://lists.gnucash.org/pipermail/gnucash-user/2026-January/119045.html * Term "split" originates in the code * Favour multi-entry for components and multi-line for CSV transaction * (glossary discussion omitted) https://lists.gnucash.org/pipermail/gnucash-user/2026-January/119050.html https://lists.gnucash.org/pipermail/gnucash-user/2026-January/119066.html * Simple/Compound/Journal-Memorandum transaction * (view comment omitted) Discussion After carefully working through the CSV import process and researching accounting terms, these comments address the thread. All agree the import process and docs contain confusing or ambiguous elements. Abstraction in coding simplifies complex systems by hiding implementation details behind simple interfaces, much like 2D maps represent a 3D spheroid. In double-entry accounting, a simple journal entry records a single debit and a single credit affecting exactly two accounts. A compound journal entry records a transaction that affects more than two accounts, so that either the debit side, credit side, or both are split across multiple accounts while total debits still equal total credits. The term "split" is used in many ways and becomes confusing with GnuCash documentation emphasising the code abstraction, where all transactions are modelled as splits (even simple two-account ones), over formal accounting usage that reserves "split" for compound entries where at least one side (debit, credit, or both) distributes across multiple accounts. The term "transaction" is simpler and more intuitive for users than the stricter accounting term "journal entry" or just "entry". Revised Tooltip Text (pending code/radio button review): Multi-line tooltip: * Disable: Each CSV line forms one simple transaction to Import Account. * Enable: Multiple consecutive CSV lines combine to form one compound transaction. Each line must provide Account and Amount, and the first line must also include Date and Description. The importer automatically groups consecutive lines into the same transaction. It starts a new transaction whenever any transaction-specific field (Transaction ID, Date, Number, Description, Notes, Transaction Commodity, or Void Reason) contains different, non-empty information. Import Account tooltip: Apply a single source account to all imported transactions. The other side of the transaction can be provided in a Transfer Account column, or left for the Import Matcher to assign. Regards > _______________________________________________ gnucash-user mailing list [email protected] To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
