I’m proud to announce that we’ve added bank reconciliation to LandlordMax. This feature allows our users to reconcile their accounting entries with their bank statements and accounts. You can find the short and fast video tutorial here as well as the full length tutorial video here. You can also find the user manual page here as well as our company blog post about it here.

I won’t got into the details of how it all works here, for that I’ll refer you to the above links. Instead I’m more going to focus on the design and implementations aspects of this feature, the behind the scenes perspective if you will.

This feature is quite interesting because what seems obvious and intuitive at first is absolutely not obvious or intuitive, at least not until you start to get into the weeds of implementing it. Some parts were pretty simple but one part especially wasn’t.

Firstly, and before going into any details, one thing to remember is that this had to be an optional feature, that is some people will use it very heavily while others may not use it at all. For this feature that wasn’t too too challenging, entries by default are set to unreconciled, and if you never reconcile them then they just remain unreconciled. You can then ignore the bank reconciliation reports, and you can even go as far as hiding that field from the table and what have you.

Our main focus was then on making the whole process of reconciling entries as easy, quick, and streamlined, with as few clicks as possible. In essence those who are going to use the feature will be using it a lot, and they want to be able to reconcile their accounting entries very quickly. They also don’t want anything overly complicated, requiring a ton of clicks and settings. And that’s where things got challenging very quickly. Making something easy and efficient takes a lot more work than most people realize. It’s like how a professional athlete makes it look easy to play a sport, sometimes it looks like they’re barely even trying, but behind the scenes we forget the thousands of hours they spent practicing and honing their skills, all that’s involved in making the actual movement look so smooth and effortless. To push this example a bit further with a more concrete example we often forget how hard it is to drive until we see someone start to learn how to drive.

And so in that vein implementing an easy and streamline process was not obvious and took a lot of effort. I’ll also preface it by saying that even things like having multiple options on how to reconcile entries took a lot of thinking and testing, and re-tweaking and adjusting. We think we’ve done a good job, especially that our users can do it so quickly with a minimal amount of clicks and effort. Select the entries in the table, right click on the entry, and pick the reconciliation status right there. If only it were that simple and that covered all the user cases, but the story doesn’t end there by any means.

Imagine someone has thousands of entries, that can make finding a particular entry a bit more challenging. Sure they can sort the entries by date, and by default they are sorted to keep the most recent entries at the top, but what if they have multiple bank accounts to reconcile or other similar scenarios? This is where things like data filters are especially useful. For example they can let the user limit the accounting entries to just unreconciled entries, greatly shrinking the list of entries on the screen. That means if they say have two bank statements, and they’ve already reconciled one statement, that they’ll then only see the entries from one bank statement (the unreconciled one). But it doesn’t end there, they can expand further by adding additional filters. They can also use the search in combination with the data filters so that the search only applies to unreconciled entries and can get very fined tuned if they prefer that approach, or the entry isn’t immediately jumping out at them on the screen. This way people with just one bank account to reconcile as well as those with multiple accounts can quickly reconcile their statements. And that’s just one example of the different types of scenarios we wanted to make sure we covered.

In other words, whatever the situation our users need to be able to quickly and efficiently find the entries they want to reconcile. They don’t want to be spending hours reconciling, if that was the case then the feature wouldn’t be very useful. And keep mind so far we’re just talking about reconciling entries which is the simplest case, we also need the ability to quickly deal with discrepant entries which includes editing the entry to add notes and so on. There’s functionality for all this and more. On a related note we also want to keep supporting the different ways people perform similar actions depending on their preference rather than forcing them to use just the one and only method we deem as the best.

The biggest and hardest challenge by far though was whether or not bank statements should be imported. That is a very big and very deep rabbit hole, and I’ll only touch the surface of it here today, but hopefully it will be enough to give you an appreciation of why we went in the direction we did.

The biggest issue with importing bank statements is that a bank statement is very limited in information. Specifically it only really contains the date and amount, and sure there is some payee information but it’s generally very limited and often coded. That and not each bank will display the payee names the same way. For example a Home Depot transaction could be “Home Depot”, or it could be “HD”, or something else. It could also change over time. And in some cases it may not even include the payee if it’s a bank transfer, or even worse, if it’s a cash deposit or something along those lines. And again if they have more than one bank statement each bank could have slightly different name for the same payee. Sometimes they will also attach location to the payee such as the address of the specific Home Depot. Meaning if they’re looking for say “HD” that could match with other payees with those letters in the name (“hd” is less common but imagine a more common abbreviation like “ne” or something like that). In essence they need some kind of mapping between the names and payee, and this has to be done for all their tenants, vendors, and so on. And that mapping could be a table of names for tenant, vendor, etc., for example multiple Home Depot locations.

Another big challenge is that bank statements do not include things such as what category type the transaction is for. For example is the transaction a rent? The bank doesn’t know or care. It’s just a transaction. For what building/unit was the rent payment made towards? For which building/unit was the toilet from Home Depot for? The bank statement has no idea. Was the rent paid on time? When was the rent due (the Date Due field in the software)? What about a description of the entry? The bank statement has no idea when a rent was due, just when it was paid. If the user imports a bank statement it doesn’t have any information on when the rents were due, if they are late, and so on. What about if someone pays cash? How does it know which transaction is for which rent based on a cash deposit? What if several rents were deposited together as one cash deposit? You would then have to have some way to split up that imported accounting entry. But how? What would that screen look like? What if it’s a tenant paying two rents at the same time combined with another tenant paying a rent? Do you show a table of accounting entries to select from and start to break it down? Again how does all that look like on the screen? Tables of tables? And what about all the information such as marking it as a rent payment rather than a toilet repair, when the rent was due, for which unit, and so on. The user would have to do a ton of data entry on top of some very complicated screen. That would be awful.

And it doesn’t end there, it just gets worse and more complicated. Just to add one more example, what happens if they decided to import a bank statement halfway through a month and then decided to re-import it again a week later, maybe with the new extra week of transactions included with the previous few weeks of transactions? What about the entries already imported? How do you confirm that entries from a previously imported statement aren’t the same? All that information also need to be stored in the software, including that an entry couldn’t been split over multiple entries. You would also need screens to be able to show that later if you’re trying to decipher what happened during your year end. The amount of screens and their complexity, not to mention all the extra work you’d have to do, gets quite large very quickly.

This kind of functionality is called merge/synchronize capabilities in software, and these can get quite unwieldy very quickly. So much that in the programming world there are software applications dedicated solely to perform these kinds of operations. As in the software whole job is just to merge code as you update it. The most famous these days is Git, and it’s quite a beast to master. I especially love this comic from XKCD about git where the end line to the question on how it’s used is: “No idea. Just memorize these shell commands and type them up to synch up. If you get errors, save your work elsewhere, delete the project, and download a fresh copy.” All that to say it is possible, and for bank transactions it will be simpler than with programming code, but even then it’s still not something that’s simple. The screens to be able to do this would add a lot of complexity to the software. You would not only need tables of the transactions on each side for those that don’t match and somehow the user would need to be able to match one with the other. Don’t forget you’d also need to confirm the matches to be safe.

Meaning even if a user were to import the bank statement, and let’s say they were lucky and matching up transactions from the bank statement wasn’t too crazy, they’d still have to go into every entry and add all the missing information manually which is a ton of work and effort, way way way way way (and yes that’s a lot of way’s) than how it’s done today which is just a click to reconcile combined with scheduled accounting entries. By using scheduled entries for rents, as well as any other recurring transaction (including expenses), then all this data entry is automatically done for them. This leaves them only with the quick and easy task of just checking the entry to reconcile and they’re done. Everything, all the information, is there for them all the time, and all it takes is a click quick to complete the reconciliation. It’s many many many (again lots of many’s) easier and very quick.

And I just touched the surface of the rabbit’s hole, it gets a lot more involved the more you get into it. Don’t get me wrong it’s possible, but it would be a whole other level of complexity and effort for our users. This by the way is also why we only see it in very expensive (and also very complex) software in our marketspace. There’s no easy and efficient way to do. Our goal is to streamline our users operations, and as you can see we believe this is much much much (yes again many much’s) more efficient and user friendly. We believe it is much better to spend a handful of minutes marking entries as reconciled than having to spend hours to manage the import and/or merge entries from a bank statement, as well as manually having to add in all the extra information that isn’t even available in the bank statement. We did look at a lot of options, and tried and tested quite a few, but we always came back to this same conclusion.

Reporting however was pretty straight forward. The main challenge here was trying to balance what our users would need and use. This lead to about 25 bank reconciliation related reports. They can of course create their own custom versions of the reconciliation reports but the provided ones should be more than ample for the vast majority of people. And as always it’s very straight forward to run the reports.

All in all this feature turned out to be a lot more involved then we initially expected. First there was a lot of time and effort, and especially a lot of working through different options and testing them to different degrees. There was a lot of testing and tweaking on the usability of processing the reconciliation status to make them so streamlined. The most challenging part was whether or not to import the transactions or rely on the scheduled accounting entries, and after a lot of deliberations and testing, we believe that using the scheduled accounting entries is the best option by a very large margin. You get all the same results with a fraction of the effort and complexity. Overall we’re very happy with how the feature turned out. It was a lot of work and it’s now available in the software. And now that it’s released, we can focus on the next features we want to add to the software!

Permalink to this article          Discussions (0)