Created attachment 373168 [details] A very simple example showing miscalculation Hello. I don't know the policy about reopening bugs. This bug is similar, but not exactly the same as bug 622778, submitted in 2010 for version 2.2.9, then fixed. I don't reopen that one, because it concerned another major version. When there is a split, GnuCash doesn't correctly calculate the cash flow. The attached file, which is essentially the same as the one posted by Fiable.biz (me) in bug #622778, shows a salary of 1 000 € paid for half by bank transfer (in cash), for half from a loan granted to the employee. Now see the cash flow report for the sole bank account, from 2010-01-01 to 2010-12-31, in euros. You'll see that the "money out" is 1 000 €, compensated by 500 € of Money in, while the Money out should be 500 €, and Money in should be 0. When there are multiple credit accounts and multiple debit accounts in a split, my idea is that the amount of money in a credit account should be, for the cash flow report calculation, regarded as distributed between the debit accounts proportionally to the total amounts affected to these debit accounts (and reciprocally, the amount of money in a debit account should be regarded as distributed between credit accounts proportionally to the amounts affected to these credit accounts). But when there is only one debit account and multiple credit accounts, or the opposite, the calculation is indisputable, and the above example shows a clear bug.
I'm not sure this is buggy behaviour. From my understanding, you (owner) pays employee (expense), using bank and loan. [A/R] A/Receivable = -500 EUR [Asset] Bank = -500 EUR [Expense] Payroll = +1000 EUR The cash-flow report by default chooses [Asset] accounts i.e. Bank only. Money in = 500EUR (from A/R) Money out = 1000EUR (to Payroll) You can choose to include both [Asset] Bank and [AR] A/Receivable accounts. Money in = 0 Money out = 1000EUR (to Payroll) It seems everything is working well. Why would the cash-flow report, reporting on the [Asset] accounts only, refuse to count the 'inflow' of 500EUR from the AR account?
The money from A/Receivable doesn't goes to the bank account. It's not a cash flow. It will never appear in my bank transactions statement. My bank cannot know it. It goes directly to the expenses (payroll) account.
Ok. I (finally) now understand the meaning of 'cash flow' report :-/ I've recently reviewed/refactored cash-flow.scm (to improve maintenance, while maintaining current behaviour) and now see how your desired behaviour is not being followed. May I ask which GnuCash version produced the 'fixed' report? I am not aware of any version that followed your desired behaviour.
More importantly let's try figure out how it should report the following multi-split transactions (assuming the same account structure above) -- and assuming only the BANK account is selected for reporting. For each one what should the resulting report be? According to the definition above, the resulting should ALL show "money-in = 0, money-out = 500eur". 1. as yours [A/R] A/Receivable = -500 EUR [Asset] Bank = -500 EUR [Expense] Payroll = +1000 EUR 2. (multisplit) [A/R] A/Receivable = -100 EUR [Asset] Bank = -500 EUR [Expense] Payroll = +600 EUR 3. (i.e. >1 split from the same target account) [A/R] A/Receivable = -100 EUR [Asset] Bank = -500 EUR [Expense] Payroll = +200 EUR [Expense] Payroll = +400 EUR 4. (i.e. >1 split from the same source account) [A/R] A/Receivable = -100 EUR [Asset] Bank = -200 EUR [Asset] Bank = -300 EUR [Expense] Payroll = +400 EUR [Expense] Else = +200 EUR 5. (complicated) [A/R] A/Receivable = -100 EUR [Asset] Bank = -500 EUR [Asset] Another = -200 EUR [Expense] Payroll = +600 EUR [Expense] Else = +200 EUR Example output: Money In: A/R 500 EUR TOTAL Money in = 500EUR Money Out: Payroll 1000 EUR TOTAL Money out = 1000EUR
Unfortunately, I don't know in what version it worked well. Rereading the discussion in bug 622778, it seems it was planned for 2.6, then withdrawn even before version 2.6 was released, so never worked correctly. On the other hand, if my memory works correctly (which is not always the case), it used to work fine during several years... My answers to your examples would be: 1) indisputably Money In: 0 EUR TOTAL Money in = 0 EUR Money Out: Payroll 500 EUR TOTAL Money out = 500 EUR 2) indisputably Money In: 0 EUR TOTAL Money in = 0 EUR Money Out: Payroll 500 EUR TOTAL Money out = 500 EUR 3) indisputably the same result as 2) 4) This is disputable, because there are both several credit accounts and several debit accounts (I never do this). My idea, expressed in my 1st post above: Money In: 0 EUR (indisputably) TOTAL Money in = 0 EUR (indisputably) Money Out: Payroll 333,33 EUR (disputable) Else 166,67 EUR (disputable) TOTAL Money out = 500 EUR (indisputably) 5) Also disputable: Money In: 0 EUR (indisputably) TOTAL Money in = 0 EUR (indisputably) Money Out: Payroll 525 EUR (disputable) Else 175 EUR (disputable) TOTAL Money out = 700 EUR (indisputably)
From IFRS for SMEs (version 2015, in force), no.7.1: "The statement of cash flows provides information about the changes in cash and cash equivalents of an entity for a reporting period" So things don't producing any change in cash or cash equivalents are not "cash flow".
I would advise to bring this conversation to the mailing list so a broader audience can have a say in this. There have been plenty of misunderstandings around how a cash flow report should work in the past. So before making any changes be sure at least a few people with an accounting background have their say in this.
@Flable.biz - fwiw I don't particularly need to fix this myself, nor do I know what would be the most correct approach accountancy-wise. Perhaps you could state your case in gnucash-user mailing list and ask the experts what should be the answer?
According to your advice, I sent a post on the mailing list on 2019-07-03, but nobody answered.
Fiable: this is probably because not many people actually feel it's a problem. I don't think your reasoning is bad -- I *can* try to fix this, via adding an option "include cash flow in/out selected accounts only". I understand your concerns relate to IFRS standards and to you this option is self-evident; but for backward compatibility it may be preferable to show previous (incorrect) behaviour as default. Is there a better name for this fix? Should the fix be the default and allow old behaviour as compatibility?
Chris, the report says that it's cash flow in/out of the selected accounts. ISTM that's what it should do. Think in terms of the selected accounts being inside a boundary and all other accounts are outside: Only the parts of transactions that cross the boundary count as cash flows. Note that the Statement of Cash Flows is IAS 7, not IFRS 7. The latter is about disclosures required of changes in value and expected cash flows from financial instruments, way beyond GnuCash's remit. But never mind about that: Cursory reading of IAS 7 (You can get a free account at https://www.ifrs.org that will enable you to read the actual standards) shows that it's not something GnuCash would be able to generate automatically: GnuCash has no way of knowing how to separate transactions between operational, financial, and investing activities, nor does it know how to separate cash equivalents ("Cash equivalents are short‑term, highly liquid investments that are readily convertible to known amounts of cash and which are subject to an insignificant risk of changes in value.") from other investments. Fiable.biz, I'll note that your use of the Accounts Receivable account as a source of funds to pay an employee is wrong. Accounts Receivable is money that you're owed by your customers. Your transaction effectively says that the customers owe the money to the employees now instead of to the company. If you have to wait for the customers to pay you to make payroll then you should create a Liabilities:Unpaid Wages account and credit that for the €500. If the customer then pays you in cash and you give the cash directly to the employees then you can flow that through an Assets:Cash account. *It's still a cash flow to you even if the bank doesn't see it!*
Created attachment 373322 [details] bug fix attempt new cash-flow.scm -- try this one new algorithm, built from scratch. modified gnucash/report/standard-reports/cash-flow.scm @@ -349,75 +349,105 @@ (to-date-t64 (cdr (assq 'to-date-t64 settings))) (from-date-t64 (cdr (assq 'from-date-t64 settings))) (report-currency (cdr (assq 'report-currency settings))) - (include-trading-accounts - (cdr (assq 'include-trading-accounts settings))) + (include-trading-accounts (cdr (assq 'include-trading-accounts settings))) (to-report-currency (cdr (assq 'to-report-currency settings))) - (money-in '()) - (money-in-collector (gnc:make-commodity-collector)) - (money-out '()) - (money-out-collector (gnc:make-commodity-collector)) (all-splits (gnc:account-get-trans-type-splits-interval accounts '() from-date-t64 to-date-t64)) - (splits-to-do (length all-splits)) - (splits-seen-list '())) - + (money-in-collector (gnc:make-commodity-collector)) + (money-out-collector (gnc:make-commodity-collector)) + (splits-to-do (length all-splits))) (let loop ((splits all-splits) + (money-in '()) + (money-out '()) (work-done 0)) - (unless (null? splits) - (if (zero? (modulo work-done 100)) - (gnc:report-percent-done (* 85 (/ work-done splits-to-do)))) + (when (zero? (modulo work-done 100)) + (gnc:report-percent-done (* 85 (/ work-done splits-to-do)))) + (cond + ((null? splits) + (for-each + (lambda (in) + (money-in-collector 'add report-currency (cdr in))) + money-in) + (for-each + (lambda (out) + (money-out-collector 'add report-currency (cdr out))) + money-out) + (list + (cons 'money-in-accounts (map car money-in)) + (cons 'money-in-alist (map + (lambda (p) + (define coll (gnc:make-commodity-collector)) + (coll 'add report-currency (cdr p)) + (list (car p) coll)) + money-in)) + (cons 'money-in-collector money-in-collector) + (cons 'money-out-accounts (map car money-out)) + (cons 'money-out-alist (map + (lambda (p) + (define coll (gnc:make-commodity-collector)) + (coll 'add report-currency (cdr p)) + (list (car p) coll)) + money-out)) + (cons 'money-out-collector money-out-collector))) + (else (let* ((split (car splits)) - (parent (xaccSplitGetParent split))) - (for-each - (lambda (s) - (let* ((s-account (xaccSplitGetAccount s)) - (s-value (xaccSplitGetValue s)) - (s-report-value (to-report-currency (xaccTransGetCurrency parent) - (abs s-value) - (xaccTransGetDate parent)))) - (cond - ((null? s-account) - (format #t "WARNING: s-account is NULL for split: ~a\n" - (gncSplitGetGUID s))) - ((or (and include-trading-accounts - (eqv? (xaccAccountGetType s-account) - ACCT-TYPE-TRADING)) - (member s-account accounts) - (member s splits-seen-list)) - #f) - ((negative? s-value) - (let ((s-account-in-collector - (or (assoc-ref money-in s-account) - (let ((coll (gnc:make-commodity-collector))) - (set! money-in - (assoc-set! money-in s-account coll)) - coll)))) - (set! splits-seen-list (cons s splits-seen-list)) - (money-in-collector 'add report-currency s-report-value) - (s-account-in-collector - 'add report-currency s-report-value))) - ((positive? s-value) - (let ((s-account-out-collector - (or (assoc-ref money-out s-account) - (let ((coll (gnc:make-commodity-collector))) - (set! money-out - (assoc-set! money-out s-account coll)) - coll)))) - (set! splits-seen-list (cons s splits-seen-list)) - (money-out-collector 'add report-currency s-report-value) - (s-account-out-collector - 'add report-currency s-report-value)))))) - (xaccTransGetSplitList parent))) - (loop (cdr splits) (1+ work-done)))) - - ;; Return an association list of results - (list - (cons 'money-in-accounts (map car money-in)) - (cons 'money-in-alist (map (lambda (p) (list (car p) (cdr p))) money-in)) - (cons 'money-in-collector money-in-collector) - (cons 'money-out-accounts (map car money-out)) - (cons 'money-out-alist (map (lambda (p) (list (car p) (cdr p))) money-out)) - (cons 'money-out-collector money-out-collector)))) + (split-value (xaccSplitGetValue split)) + (txn (xaccSplitGetParent split)) + (txn-splits (xaccTransGetSplitList txn)) + (all-neg-splits (filter (compose negative? xaccSplitGetValue) + txn-splits)) + (all-pos-splits (filter (compose positive? xaccSplitGetValue) + txn-splits))) + (cond + ((or (zero? split-value) + (and include-trading-accounts + (eqv? (xaccAccountGetType (xaccSplitGetAccount split)) + ACCT-TYPE-TRADING))) + (loop (cdr splits) + money-in + money-out + (1+ work-done))) + ((negative? split-value) + (let ((frac (/ split-value + (apply + (map xaccSplitGetValue all-neg-splits))))) + (loop (cdr splits) + money-in + (let lp ((all-pos-splits all-pos-splits)) + (if (null? all-pos-splits) + money-out + (let* ((pos-split (car all-pos-splits)) + (pos-acct (xaccSplitGetAccount pos-split)) + (pos-val (to-report-currency + (xaccTransGetCurrency txn) + (abs (xaccSplitGetValue pos-split)) + (xaccTransGetDate txn))) + (prev-bal (or (assoc-ref money-out pos-acct) 0))) + (set! money-out + (assoc-set! money-out pos-acct + (+ prev-bal (* pos-val frac)))) + (lp (cdr all-pos-splits))))) + (1+ work-done)))) + ((positive? split-value) + (let ((frac (/ split-value + (apply + (map xaccSplitGetValue all-pos-splits))))) + (loop (cdr splits) + (let lp ((all-neg-splits all-neg-splits)) + (if (null? all-neg-splits) + money-in + (let* ((neg-split (car all-neg-splits)) + (neg-acct (xaccSplitGetAccount neg-split)) + (neg-val (to-report-currency + (xaccTransGetCurrency txn) + (abs (xaccSplitGetValue neg-split)) + (xaccTransGetDate txn))) + (prev-bal (or (assoc-ref money-in neg-acct) 0))) + (set! money-in + (assoc-set! money-in + neg-acct + (+ prev-bal (* neg-val frac)))) + (lp (cdr all-neg-splits))))) + money-out + (1+ work-done)))))))))))
Created attachment 373323 [details] 2nd attempt 2nd attempt. ignore intra-transaction splits.
@ Christopher Lam, comment 10: thank you very much. To my mind, it would be better that the default behaviour be the correct one (Think also of GnuCash newcomers.), but it's not very important to me.
On Jul 14, 2019, at 3:41 PM, Fiable.biz <mongolie2006-gnu@yahoo.fr> wrote: > Hello. > Thank you. You wrote: > Fiable.biz, I'll note that your use of the Accounts Receivable account as a > source of funds to pay an employee is wrong. Accounts Receivable is money > that you're owed by your customers. Your transaction effectively says that > the customers owe the money to the employees now instead of to the company. > If you have to wait for the customers to pay you to make payroll then you > should create a Liabilities:Unpaid Wages account and credit that for the > €500. If the customer then pays you in cash and you give the cash directly to > the employees then you can flow that through an Assets:Cash account. *It's > still a cash flow to you even if the bank doesn't see it!* > > Why Accounts Receivable should be money owed by my customer? Cannot it be > money owned by an employee? > My story was "a salary of 1 000 € paid for half by bank transfer (in cash), > for half from a loan granted to the employee.". Do not write to the developers directly, use the mailing lists. For bugs discussions should be kept on the list. "Accounts Receivable" and "Accounts Payable" are terms-of-art used to denote accounts for accumulating money owed to the business due to sales and owed by the business due to purchases, generally for operations when the business does "accrual accounting" (as opposed to "cash accounting"). I'll leave it to you to study up on the differences. In GnuCash the Accounts Receivable and Accounts Payable account types are further reserved for use by the business features: Bills and Invoices. If you make loans to employees then you should have an asset account called Loans to Employees to separate those transactions from your other operations, and you should consult with a locally licensed accountant for guidance in how to reflect it in your financial and tax reports.
It would seem there are two opposing views with this issue. See bug 722140 for the other one. I think there should be an option for selecting the preferred algorithm.
Thanks for finding that. We need Geert to weigh in again, so we'll need to wait for a couple of weeks. It doesn't change my view, though: The current behavior turns the cash flow report into a weird sort of P&L/Income Statement. There does seem to be some demand for it and apparently the competition provides something like it, so I guess we should keep the functionality. If it's an option then users will fight over which should be the default; I'm inclined towards separate reports.
At the very minimum, IMHO the current cash-flow.scm could remain untouched (or a basic chris's optimisation!) and the labels changed from Money into selected accounts comes from Money In £0.00 Money out of selected accounts goes to Money Out £0.00 Difference £0.00 to Transactions involving selected accounts include funds from Money In £0.00 Transactions involving selected accounts include funds to Money Out £0.00 Difference £0.00
The pending branch https://github.com/Gnucash/gnucash/pull/537 will modify the original report name to "Cash Flow (Transaction)", and headings changed to the following: "Transactions involving selected accounts are funded from" "Transactions involving selected accounts fund" and creates another report named "Cash Flow (Account)" headings as per current report, incorporating this bug's algorithm. I still think that the original report could add an option, defaulting to transaction cashflow.
You need to add "also" to the new headings, as in "Transactions involving selected accounts are also funded from". Maybe also change "Difference" to "Change in value of selected accounts". I see that you went with the "ratio" approach to allocating amounts to source and destination accounts. Since there hasn't been any response to my clarification of Fiable.biz's original, I guess nobody really cares.
You need to add "also" to the new headings, as in "Transactions involving selected accounts are also funded from". Maybe also change "Difference" to "Change in value of selected accounts". --> Well if "cash-flow (transaction)" is run querying inc/exp accounts then the text would fail because we'd need to use "Transactions involving selected accounts *also* fund". Pushed. I see that you went with the "ratio" approach to allocating amounts to source and destination accounts. Since there hasn't been any response to my clarification of Fiable.biz's original, I guess nobody really cares. --> exactly... so perhaps modifying current report to use secondary algorithm as an option is better?
> "Transactions involving selected accounts *also* fund". Of course. I said "headings", plural. > exactly... so perhaps modifying current report to use secondary algorithm as an option is better? Why? With which value as the default? And what for option labels? I don't much care for "Cash Flow (transaction)" and "Cash Flow (account)" either. The first isn't really a cash flow report, and both of them involve both transactions and accounts. I just haven't yet figured out what the current report really is besides weird.
(In reply to Fiable.biz from comment #2) > The money from A/Receivable doesn't goes to the bank account. It's not a > cash flow. It will never appear in my bank transactions statement. My bank > cannot know it. It goes directly to the expenses (payroll) account. I fear this will be a long discussion to get to the bottom of it. To start I don't claim any expert knowledge on this particular topic. Having said that and in reply to your particular message above: the representation of your data in gnucash is not necessarily how your bank sees it. It should represent your accounting story. Secondly it appears there are multiple interpretations of the term "cash flow". The only one I have used so far is neither how the current cash flow report works, nor how you want it to work. From a business perspective here in Belgium we use net profits + deprecations (and optionally other corrections) as practical cash flow value. This is derived from a profit and loss report and doesn't need a cash flow report for all the details on a split level. As several others I have yet to fully determine what the current cash flow report is supposed to express. From the strong defenders in bug 722140 it appears to be a cash flow report is supposed to divide a set of accounts in two groups (the included and excluded account) and then list all splits from the excluded accounts as a detailed illustration how the included accounts have reached their current balance. I have a feeling "cash" in the "cash flow" title is the ambiguous bit here. It's clearly a "flow", but not all that flows is true cash. It's a move of amounts from one set of accounts to another. Applying that to your initial example, if you select only the bank account the 'cash' flow report should indeed list all the moves, not only ones we consider actual ('real') money moves.
(In reply to Fiable.biz from comment #6) > From IFRS for SMEs (version 2015, in force), no.7.1: > "The statement of cash flows provides information about the changes in cash > and cash equivalents of an entity for a reporting period" > So things don't producing any change in cash or cash equivalents are not > "cash flow". Isn't a liability a cash equivalent ?
(In reply to John Ralls from comment #17) > Thanks for finding that. We need Geert to weigh in again, so we'll need to > wait for a couple of weeks. > > It doesn't change my view, though: The current behavior turns the cash flow > report into a weird sort of P&L/Income Statement. There does seem to be some > demand for it and apparently the competition provides something like it, so > I guess we should keep the functionality. If it's an option then users will > fight over which should be the default; I'm inclined towards separate > reports. I'm confused here. What do you mean with "current behavior" ? The behavior the currently released report shows or the one implemeted by chris ? And how does that look like a weird sort of P&L/Income Statement ?
(In reply to Geert Janssens from comment #24) > (In reply to Fiable.biz from comment #6) > > From IFRS for SMEs (version 2015, in force), no.7.1: > > "The statement of cash flows provides information about the changes in cash > > and cash equivalents of an entity for a reporting period" > > So things don't producing any change in cash or cash equivalents are not > > "cash flow". > > Isn't a liability a cash equivalent ? Oh, never mind that. John answered this is comment 11.
(In reply to John Ralls from comment #20) > You need to add "also" to the new headings, as in "Transactions involving > selected accounts are also funded from". Perhaps it's because my native tongue isn't English: what does the word "also" add to this sentence ? And while it may be technically more correct I find it a rather complicated title to use. I had to read it five time to grasp what it conveys :( > Maybe also change "Difference" to > "Change in value of selected accounts". > That's a change I do like. > I see that you went with the "ratio" approach to allocating amounts to > source and destination accounts. Since there hasn't been any response to my > clarification of Fiable.biz's original, I guess nobody really cares. Nobody cares *yet*. Wait until this gets released :) More seriously, I do feel uneasy about this. I don't think an accounting package should make assumptions like this (as I wrote in bug 722140 comment 35 (https://bugs.gnucash.org/show_bug.cgi?id=722140#c35). It can't know exact allocations between credits and debits unless the transactions balance. If we deliberately leave out information (as unwanted according to this bug report) the incomplete transaction doesn't have enough information to automatically perform allocations. Considering this I have my doubts about the updated report's value. It may produce fancy numbers that don't mean anything.
(In reply to John Ralls from comment #17) > Thanks for finding that. We need Geert to weigh in again, so we'll need to > wait for a couple of weeks. > > It doesn't change my view, though: The current behavior turns the cash flow > report into a weird sort of P&L/Income Statement. There does seem to be some > demand for it and apparently the competition provides something like it, so > I guess we should keep the functionality. If it's an option then users will > fight over which should be the default; I'm inclined towards separate > reports. So from reading the rest of this, it looks like with "current behavior" you mean after chris' changes. I'm really interested to learn more details about what the competition really is providing and how they deal with ambiguous allocations or how they manage to avoid them.
(In reply to John Ralls from comment #22) > > "Transactions involving selected accounts *also* fund". > > Of course. I said "headings", plural. > > > exactly... so perhaps modifying current report to use secondary algorithm as an option is better? > > Why? With which value as the default? And what for option labels? > > I don't much care for "Cash Flow (transaction)" and "Cash Flow (account)" > either. The first isn't really a cash flow report, and both of them involve > both transactions and accounts. I just haven't yet figured out what the > current report really is besides weird. Agreed. I think we can conclude that "Cash Flow" is a misleading name for this report. But I have no idea what is should be called. It details flows between two groups of accounts, but these flows may or may not be "cash". "Fund Flow" perhaps, following chris' suggested title changes ? I'll note the Dutch wikipedia page on Cash Flow ("Kasstroom", https://nl.wikipedia.org/wiki/Kasstroom) is completely different from the English one (https://en.wikipedia.org/wiki/Cash_flow). The English one is more elaborate. On the Dutch one cash flow is loosely defined as the difference between income and expenses. The English definitions are more abstract. Our current "Cash Flow" report won't allow to report only the difference between income and expenses (as a summary or in detail) so that's another indicator the report's name is wrong.
Geert, Welcome back! It's the current implementation that I think is a weird sort of P&L report because it presents (possibly imaginary, as in the case of Fiable.biz reducing his employee's pay to collect on the loan) flows that don't cross the report boundary as if they do. If all of your asset and liability accounts are inside the report boundary and equity is outside, as the reporter in bug 722140 did, the result is the P&L report with misleading headings. "Transactions involving selected accounts are funded from" indicates that the subsequent list contains all of the funding sources while "Transactions involving selected accounts are also funded from" indicates that the subsequent list of funding sources is in addition to the sources already listed, that is the accounts "inside the report boundary". The English "Cash Flow" Wikipedia page covers more cases than the Dutch one, but they agree on the meaning for accounting purposes. From the Dutch one, translated by Google: "For determining cash flows, it is important to make a distinction between costs and revenues on the one hand and expenditure and receipts on the other . The profit is calculated on the basis of the first pair and the net cash flow on the basis of the second pair." That's equivalent to the English page's "cash flow can be used to evaluate the 'quality' of income generated by accrual accounting. When net income is composed of large non-cash items it is considered low quality." and a lot clearer. To make that concrete, if XYZ corp. made 100M in income last period but 90M is still in A/R, their inbound cash flow is only 10M. If they were able to string along their suppliers so that of their 90 in expenses 80M is still in A/P (and their employees work for free, no taxes are due, etc.) then they have a profit of 10 for the period but their cash flow is 0. A real XYZ corp's expenses are going to be more like 30M to suppliers, 30M to employees, 5M of depreciation, and 15M in taxes... and only the first 30M can stay in A/P. That means that even though they have a 20M profit for the period they have a -35M cash flow (and angry suppliers who might not sell them more until they pay up). Keep that up for long and the company will fail even though it's nominally profitable. That's the Cash Flow of IAS 7. US GAAP has similar requirements. But aside from Fiable's misuse of "Accounts Receivable" instead of "Loans to Employees" there's no indication that either he or the reporters of bug 722140 are using accrual accounting. All of the flows here are immediate and would be considered cash in the IAS 7 sense, it's just a matter of whether or not to display flows that happen outside of the report's boundaries.
@John Ralls, although @Fiable.biz hasn't weighed in explicitly on this, the idea that an employee would have an AR account is not uncommon. Perhaps the employee purchased goods/services from the company on account. That account was then offset by unpaid but later earned wages/salary. In that case, the original example is proper. However, in response to comment 6, the assertion that this AR split should not affect the Statement of Cash Flows is incorrect. The Operations section of that report *is* to be affected by changes to non-cash operating capital, and specifically, these include accounts such as AR, AP, and inventory. (that is, for indirect method calculations of this section) If one were using the direct method, then it would be a sum of actual cash changes, and in that case, AR (and other non-cash accounts) would not be included in the formula.
> Perhaps the employee purchased goods/services from the company on account. That account was then offset by unpaid but later earned wages/salary. In that case, the original example is proper. I don't think this is a problem. The employee is very well allowed to have a loan from employer. I think the main issue that jralls is not happy about (and by extension, GnuCash cannot well handle) is a manually-created transaction involving AP/AR account and other account types. Therefore a loan to employee, initial loan and settlement manually entered (without invoices & bills) *should* be recorded in an Asset:LoanToEmployee account rather than A/Receivable, at the very least to satisfy GnuCash engine assumptions. If however the loan to employee was offered an invoice, then later settled via a payment, this will still be a regular 2-split transaction entered *via business features* and can never be a multisplit transaction. I'll leave all accounting interpretation to other experts. I have had no formal finance training myself (except from thorough understanding of GnuCash Tutorial and Concept Guide!)
Sorry, I didn't notice the .gnucash attachment. I see what's going on now. (I suppose business features could have been used however. I do mulit-split payments often and it handles it just fine.) If the report is trying to mimic the indirect method calculation, then it is working correctly at least with the net result. (even though the formatting is not up to IFRS/US standards) But if it is trying to do a direct calculation, Fiable is right, it should only be showing the 500 out (credit) from the Bank account without any other data. (the direct method only adds *actual* receipts and disbursements) Pending further experimentation with some examples, it looks like as long as you select only your cash & cash equivalent accounts, you *should* get the correct Operating Activity section of the formal report in the 'Difference' line. (again, without the proper breakdown —just a single figure) I shudder to imagine though what the report would look like with Investing and Financing accounts mixed in though in its current form. It probably wouldn't be of much use save to simply see the net change in cash position.
@Christopher from Comment 4, yes, at least 4 of those should show only 500 out with nothing in, using the Direct Method calculation. (you *only* add receipts and subtract disbursements of cash and cash equivalents.) I don't think Fiable's notes on #4 & 5 are correct in comment 5 because this method only looks at the cash accounts. It doesn't matter why the cash was disbursed, only that it was cash. So there's no looking at Payroll or Else or AR at all. In example 5, you have 'Another' asset. Is that cash or cash equivalent? If so, then total out is 700 with 0 in. If however it is not cash/equivalent, then it doesn't get factored in. Now, using the Indirect Method, you'd have to factor in the total net change in AR as a deduction from Net Earnings. (before interest and taxes, or EBIT) That however requires you start with the cash balance from the prior period balance sheet. (not fun) You still wouldn't look at Payroll or other Expenses. (unless they happen to be Depreciation or Amortization, which are part of another deduction from EBIT) Now that I ponder it though, the effect of the current report *might* happen to work out to be the proper result in the end since by looking at all of the splits it is factoring in all the calculations leading to EBIT. (and the splits it shouldn't be considering get cancelled out in the process) So it ends up telling you the change in cash, just with lots of noise. The only major issue then is the format of the report is nothing like what IFRS/US suggest/require for a Statement of Cash Flows.
Studying how the report is 'supposed' to look and what it should include, I think the premise of the current report is perhaps backwards, or misleading. Rather than ask 'from where does money flow into the selected accounts' and then 'Where does money from the selected accounts go to', instead, the report should be answering the question 'what is the net of the credits/debits for *only* the selected accounts' The user would then only select their cash/equivalent accounts in the Accounts tab. The report only needs to look at the splits in any transaction for just those accounts and do a sum. For a full proper report, The three different sections (Operations, Investing & Financing) would need each their own account selections. And perhaps, maybe even the accounts themselves need special type designations to facilitate a proper report. In the meantime, I offer the current report be renamed 'Transaction Flow Report' as a first suggestion. It is a useful report to see where funds are coming from and going to with respect to an account or set of accounts. But this isn't necessarily a proper 'Cash Flow' report.
(In reply to Adrien from comment #34) > (snip) So it > ends up telling you the change in cash, just with lots of noise. The only > major issue then is the format of the report is nothing like what IFRS/US > suggest/require for a Statement of Cash Flows. Note the report doesn't claim to be a "Statement of Cash Flows", it just states "Cash Flow". I make the distinction because there are separate wikipedia pages for "Cash Flow" and "Statement of Cash Flows" (at least in Dutch) so they are not exactly the same. I imagine to have gnucash generate a full "Statemenet of Cash Flows" autonomously we likely have to define at least 3 account types, or find a way to tag accounts with 3 different tags so we can classify them properly for the 3 types of cash flow found in the Statement of Cash Flows. We currently don't have something like that which perhaps explains why the report is stuck at doing what it currently does.
I think if we want to have a proper IFRS/IAS genuine report then we need another report altogether. Feel free to discuss in devel what it involves. I have no idea what Operating/Investing/Financing accounts are -- are they ASSET/LIAB or INC/EXP or AP/AR accounts? Would STOCK/FUND accounts be featured (:-o) :clueless: For this cash-flow.scm the issues remain (1) it's badly named (2) its interpretation of money-flow remains fuzzy (3) using manual splits in APAR accounts will break some assumptions in gnc engine.
I think it unlikely that Herbert Thoma had a formal statement of cash flows in mind when he wrote this report. Let's immediately change the name of this report and this bug to remove any connection to the Statement of Cash Flows and to cash and cash equivalents. It doesn't have anything to do with either. "Flow of Funds" or "Money Flow" or even "Asset Flow" (to make it clear that any commodity might be included if that's the case) are potential new names. With that confusion out of the way we can focus on the central question of this bug is whether the report should be account-based, transaction based, or both controlled either by an option or by separate report names. There's clearly a constituency for both, but how to apportion the flows in the account-based case is an open question. As for a proper Statement of Cash Flows, I don't think we want to go there. It would require adding a layer of classification on either transactions or accounts and (here's the really sticky bit) perfect discipline on the part of the user in applying the classification when creating transactions. That works for companies large enough to have dedicated accounting departments, not so much for the small business owner trying to do her own bookkeeping. It's also unlikely that that small business owner is going to have non-operational cash flows to worry about nor to have anyone to report them to.
Hello. I don't have the latest version of GnuCash, but version 4.2. It seems after 2 years, and more than eleven years after bug #622778 was reported, nothing has been released yet... In fact, I use the "cash flow" report for many more things than just cash, because Mongolia's Ministry of finances required details of many flows. I have to fill many small tables with the increase and decrease of many things, from my products for sale to my computer equipment depreciation, and I do this with "Cash flow" reports, choosing as "cash" accounts the accounts concerned by the table. For instance choosing the "Machinery and equipment" account and all its sub-accounts gives me the increase and decrease of value of "Machinery and equipment", which are required for legal reasons. So I would be very grateful if I wouldn't have to correct manually the figures produced by GnuCash.
I realize this is an old thread, but GnuCash still desperately needs a proper statement of Cash Flows. I realize we'd have to categorize accounts by operating, financing and investing activities. It could be an optional feature that those of us who use GnuCash for businesses (or accounting-savvy personal users) could use. The current "Cash Flow" report is misleading at the least, and does not provide any useful information about the actual cash flow.
