Receipts and Payment qty / unit price column

Manager already does this. You need just single receipt or payment to concieve any single bank statement line, no matter how complex it is to split.

But I’m already doing this. Description field on payment level is meant to be description on bank statement line. Or do you think we need one more description field?

We still need cleared field because you can have outstanding deposits, unpresented cheques. And in these cases, transaction on bank statement will clear on different date than is your accounting date. So we do need option for two dates.

This is the direction I’m taking.

I actually like when discrepancies have direct effect on financial statements. This is forcing you to fix it as soon as possible. Also, it makes your Cash at bank balance accurate even if there are discrepancies at the cost of having the difference in Suspense account.

1 Like

But we don’t have bank lines inside Manager to begin with? When we have those then we can transform them to match the books.

Take this for example, daily I collect 100 cheques from customers, the lazy bank batch processes them and groups their own cheques in 1 single line per day labeled:

Deposit Home CHQs.

Now I don’t want to create a single receipt in Manager that overwrites all my detailed work especially since I want to issue each customer with a receipt addressed to them as acknowledgment for their payment.

Preferably, when I import the bank statement, each line is assigned a unique id and later when I split the bank line I can get children that inherit their parent’s id. Then I can embed each of the children in a single receipt.

I know that this is a complex model, but this is what some banks actually do in real life and it has to be done if we are to document the reality of the transaction as faithfully as possible.

Maybe the child-parent thing is a bit overboard at the moment but at least we have something to group the split bank lines back together in order to be able to view the bank statements as imported. It could be anything; a text string could do just fine.

Yes, in order to accommodate a mixed manual + import approach. The user can create receipts on the spot with meaningful descriptions and then embed the entire bank line within that receipt:

  • Bank date
  • Bank amount and
  • Bank’s gibberish for a description.

This way we can have three options for bank import lines, either:

  • Create a new transaction based on the bank line where the user can assign a meaningful description and not lose the bank’s gibberish.
  • Append the entire bank line to a transaction that has no bank line.
  • If the user already entered the bank details manually, that bank line can be ignored.

Fair enough.

That’s absolutely fine as long as it’s apparent on the transaction itself. Both on view and edit screens as well as in the tab views of:

  • Receipts
  • Payments
  • Bank and Cash

We do. Depends how you look at it. When you mark payment or receipt Cleared, then the payments and receipts themselves represent bank statement lines at the same time.

You can have separate cash account which you can call Undeposited Cheques. Enter these cheques into this cash account and when deposited, you can create inter-account trasfer.

Sure, it doesn’t model reality 100% but do you think you will be still receiving cheques from customers 20 years from now? The long-term trend is more digital and less paper.

  • Bank date is Cleared date
  • Bank amount is Fixed total
  • Bank description is Description field on payment.

So we have all these fields to capture bank statement line within receipt.

I wouldn’t mind to group these fields together on receipt and payment to indicate these fields represent bank statement line. This way it would be more obvious that receipts and payments contain bank statement line information within them. And there is no matching because receipt or payment = bank statement line.

I don’t even know if I am going to stick around for that long. All I know is that I need to solve my present problems if I want to have a decent life 20 years from now. :grin:

I don’t like using Inter-account transfers since they don’t mesh well with bank imports and are likely to cause duplication. That’s why I use them very judiciously at this point in time.

But that will be a solution once Inter-account transfers are integrated into all this, eventually. :crossed_fingers:

That makes sense. And while we’re at it, why not name all these fields more descriptively, eg:

  • Cleared date, bank description and matched amount, or
  • Bank date, bank description and bank amount.

I personally prefer the first naming system but regardless, I would definitely drop the name “Fixed total” because it’s a bit generic and quite confusing.

I know it’s a general idea you have for other forms as well but I think the name should make sense in each context. For example I think it’s more suitable to be called “Invoice total” when used in the context of Purchase Invoices.

Also, even if we are going to keep the discrepancies in suspense, the discrepancy should be obvious just like my earlier example about how it’s handled in Journal Entries.

I don’t want to wait until I go clear out my suspense account; I want to see it as I type my lines, when I view the transaction and when I view the related tabs.

And finally, I kept the best till last:

Can we use those to recreate the original bank statement within Manager? I’d really love to hear that that’s one of the end goals to all these improvements.

This would be helpful in determining what went wrong in case of a reconciliation discrepancy.

This way we have three types of discrepancies:

  1. Transactions with no Fixed Total. Pretty easy to spot and fix.
  2. Duplicate Fixed Totals. Impossible to spot without direct comparison to the lines of bank statements.
  3. Fixed Total amount different from bank line. Also impossible to spot without comparison to the lines of bank statements.

Is this method fool proof in terms of points 2 & 3? If not, can these comparison be somehow done for us by Manager?

When you go to Bank & Cash Accounts tab, then click on balance under Statement balance column, that should give you bank statement transactions.

So only Cleared transactions and the Date will be Cleared date, not Transaction date.

I tried using it once but it confused me since it almost always never matches either my book balance or my bank balance when I need to reconcile my banks every month. So I can’t use it either as my starting point or as my end goal.

That’s why every month I go to the summary screen and copy the bank transactions from there, then I run a match against bank statements in a spreadsheet. Then I filter out the matched bank lines and import the unmatched bank lines.

Only then do I create a bank reconciliation after the fact to show to my clients.

But that doesn’t answer my other two questions:

That is superfluous if brought together under “from bank statement (line)”

It should match your bank balance.

You mean duplicate transactions? This would be uncovered by Bank Reconciliations tab.

Again. Bank Reconciliations tab would uncover them.

That’s after reconciliation. Before reconciliation it’s not very useful and after reconciliation it’s already history.

Bank Reconciliations will only tell me something is off – in general. It wouldn’t help pinpointing what went wrong or how it went wrong like whether a discrepany is of type 1, 2 or 3, for example.

As it stands right now, I can mark a wrong transaction as cleared with a wrong date and wrong amount and the effects are:

  • The statement balance in bank and cash will be off.

  • The wrong transaction wouldn’t appear in the bank reconciliation table as a reconciling item.

I see some room for improvement.

@Ealfardan but Bank Reconciliations tab is not just indicator something is off. There is also workflow built-in to find out which specific day does not reconcile.

See: Reconcile bank accounts | Manager

That’s exactly what I have been talking about for the better part of two years.

If only Manager could see the bank statements, then it would stop asking me to look at them myself. :slightly_smiling_face:

Could this manual lookup and comparison be done from within Manager without going back and forth to external spreadsheets?

1 Like

What is meant by these words is some what confused.

  • if “Bank reconciliation” means what is done in Managers bank reconciliation tab, then that definition is best served by Managers bank reconciliation tab.

  • if “Bank reconciliation” means having a efficient method of verifying correspondence between a banks records and Manager’s records, then we can have a useful discussion.

Err
There appears to be some confusion as that’s not what I was suggesting.

Essentially I am trying to address a broader range of use cases, supporting more flexible use of Manager.

In more detail I had envisioned

  1. Retain Managers reconciliation tab as it is. When only paper bank records are available it is the most efficient way of doing bank reconciliation. Its weakness for “Bank reconciliation” is the bank running total only needs to match on the date the reconciliation is done for it to pass. Similarly finding differences involves a significant amount of Manual work.

  2. Enhance “Bank import” to a) Show lines which do not match in Manager as well as the current in the import b) Show lines which are likely to correspond but have a small difference eg clearance date c) optionally showing lines which have been computer matched maybe useful but that would depend how well points a & b work for users.

I had envisioned both the “Bank reconciliation” tab and the “Bank import” would retain the ability to be redone at any time.

The bank import matching should automate a similar thing to the old manual process ie scanning thorough the bank and Managers records, crossing off the easy matches first, eventually leaving entries which can not readily be matched. A possible algorithm is some thing like

  1. Match exact date, amount, description
  2. Match exact date, amount, bank rule account & Manager account
  3. Match exact date, amount (with any description & account)
  4. Steps 4, 5, 6, 7, 8, 9,… repeat steps 1-3 for dates near. Useful to detect bank clearance date for cheques or manually entered transactions.

Manager then displays lines which do not match and what ever level of matched transactions a user find helpful (probably level > 3). While it is true in some data sets with repeated virtually identical entries, repeated run may match slightly different items however what is left over & displayed to the user would still be constant and informative.

Use cases

  1. For purely manual bank records. Continue to use the reconciliation tab and manually entered bank transactions.

  2. For uses who like the way Manager currently does bank imports. Continue using it as before, no functional change should be noticed. Continuing to also use Managers “Bank reconciliation” tab is recommended to ensure the running totals match particularly at the end of financial periods.

  3. For users who enter some bank transactions manually but still want to use bank imports, Manager would then support their work flow. A work flow which minimises the inconvenience of Manager not having live feeds for all banks.

  4. For uses who want to audit bank records against Managers records, Manager would then support their work flow. Bank records could be re imported for a period of interest and any differences would be highlighted. This would pick up any changes made to Managers amount or date for any line item in the bank records, the differences may correspond to errors or legitimate changes. An example of a legitimate change is BAS (or other large bill) paid via more than one bank transaction (due to electronic transfer limits imposed by the bank) but combined into one transaction in Manager then distributed to multiple accounts. Such a transaction would result in three miss matched entries on bank import justifiable to any auditor.

1 Like

That could also work as long as it doesn’t result in duplicates.

I can imagine that instead of the bank reconciliation discrepancy screen telling me to manually scan a bank statement for discrepancies, Manager asks for another upload where it looks up the bank data it stores against the newly uploaded bank statements.

I’m all in for that.