Bank Reconciliation Alternative Work Flow

Hi all,

After having multiple discussions on both how the reconciliations are handled as well as how receipts, payments and transfers are entered. I was thinking there might be a better and simpler way to handle all of this which is also much more efficient for bank entries and provides better audit trial over bank reconciliation and matching.

Instead of maintaing clearing date (which is good but imperfect), why not import bank statements as a separate record which is outside the general ledger records. These records should be matched to receipts and payments and interaccount transfers in a many to many relationship which should involve a matching table.

The process:

  1. Enter receipts and payments and interaccount transfers manually or in batch.

  2. Import bank statements.

  3. Verify the bank balance movement analysis.

  4. Manager identifies direct matches and leaves the remaining for the user to match.

  5. The user will match all what is there to match and then there will remain Transactions in bank not matched to books which can be batch entered to suspense and Transactions in books not matched to bank which will be flagged for the user to correct or delete.

Advantages:

  1. Manager keeps track of the entire bank records as an external record.

  2. Manager forces the user to post all bank entries at the time of reconciliation.

  3. The reconciliation equation
    Bank balance = Book balance + Transactions in bank not matched to books - Transactions in books not matched to bank will always hold true as long as the bank records are complete.

  4. Using a unique matching reference that can accomodate many to many relationships is far superior that the use of a one way cross-reference (i.e. clearing date) that is not unique and provides no help in case of a mistake.

  5. Many to many can also mean that we can reconcile individual entries to batch entries both ways which should accomodate for differences in granularity of records.

  6. This way it will be easier to correct mistakes in the reco easily by tracing matching reference to bank statement. Basically fool proof.

  7. Another discrepancy that this method can uncover is if the amounts matched are different, which the cleared date cross reference fails to identify.

  8. This should keep import of bank statements outside of receipts and payments so that the cashier cannot access this function.

Disadvantages:

  1. A very big departure from what manager is doing right now and might require a lot of work to pull off.

  2. There is currently nothing in manager similar to the matching function proposed but I believe @lubos is smart and can make it work.

I have implemented this method in my firm 3 years ago and this has made my life much easier since it broke down reconciliation into bite sized chunks for employees to understand, lowered my training efforts, no need for rework since there is a trail to go over mistakes and imperfect matches and it works every single time.

Your feedback is welcome guys.

Note: I will soon share the excel sheet to show how this works.

I see many shortcomings to this approach:

  • You are both entering receipts and payments manually and importing statements. Why do both? The entire point of imports is to avoid manual entries, if that suits your needs.
  • Why should Manager maintain an external record of all bank transactions? It has an internal record. The bank has the external record. You are only introducing an extraneous, secondary source.
  • What is the use of many-to-many matching? When reconciling accounts, you can only match one to one.
  • What difference does it make that clearing dates are not unique? That is only one thing you match when reconciling. You also match payer/payee and amount.
  • Why should there be differences in granularity of records? You called this an advantage, but it seems irrelevant.
  • Users may not use Bank Reconciliations at all. For one of my businesses, for example, I compare the cleared balance in the Bank Accounts tab to my online bank balance. If they match, I consider them reconciled. If they don’t, a quick drill-down in Manager can be compared to the online transaction list for the bank account much quicker than navigating through Manager’s reconciliation correction process. And I have no need to produce a report for myself as the sole proprietor of that particular business.

I have no doubt you have worked out a process that meets your particular needs. But as a general suggestion, this looks like a solution in search of a problem.

This is probably the only time that @Tut and I would agree whole heartedly.

The whole point of bank imports is to automate the process of entering payments and receipts. Why do all the work manually and then import the statement as well? You are just creating extra work for yourself.

By attaching the bank statement pdf document to the bank reconciliation transaction in Manager, you have both the external and internal records.

I would suggest that you clone your business and one month do just weekly bank imports in the cloned business instead of manually adding payments and receipts. Obviously you still need to create sales invoices receipts or whatever you give to the customer. Try that and then see.

I can tell you that it would add a huge level of complexity to the program to create many to many relationships in the way you suggest. It would not be a trivial programming task and I just can’t see many people using such a complicated way of reconciling bank accounts when bank imports does it in two clicks as it were.

Is there a way that you could simply import the bank statement and handle whatever it is you require another way? For example, perhaps receipts for cash transactions could be done in the same way as sales invoices - where you can create the receipt to give to the customer without actually creating the transaction in the bank account.

One flaw in your current design is that your payments and receipts does not match up with what is on your bank statement so when the taxman is looking at your bank statements, it is much harder to see the transactions in Manager matching up with what your bank says you have earned.

I think the question you need to ask is why do you need to process bank transactions manually. What are you trying to achieve that cannot be done with a bank import.

Agree this would work well as it enables the user or use what ever mixture on manual entry and importing bank transactions they find optimal for their work flow.

For a summary of a possible implementation and work flow see

I agree this is the major disadvantage, which is why I didn’t bother to further describe how it would increase user efficiency so increase the value of Manager. Particularly given other limitations of manager I consider more pressing such as Inconsistency in Tax-reporting and Improvement to payment and receipt forms and for Managers international appeal working out a way to make localisations work and real support for multi part tax codes Future Tax code structure ideas

For my use case I can just give up on manual entry, so it doesn’t really worry me either way.