Auto-convert downloaded transactions to human readable descriptions
The data downloaded from the bank is a wonderful thing, all the information is provided, but it would be really nice if the descriptions were in human readable form. I'm sure many people, like myself, use certain gas stations or ATMs on a regular basis for example, but the banking world appear to have no grasp on reality. Here's a few examples to illustrate the point:
Bank entry: CT VCOM HONOR 1965001V 02/09/
display as: ATM at 7/11 @ 48st/McDowell
Bank entry: DIAMOND 1635 SHAMROCK PHOENIX AZ
display as: Diamond Shamrock @ 44st/McDowell
Some entries go so far as to include the date and time of the transaction - that's great info, but they don't need to appear as a separate payee. That info can be stored in the transaction register, and just the basic information displayed. One way to achieve this would be a substitution table where the user could enter part of the bank code and a matched tag of the desired display code.
In the case of the first entry, "CT VCOM HONOR 1965001V 02/09/", the "02/09/" at the end is part of the date of the transaction, so any entry which begins with "CT VCOM HONOR 1965001V" should be displayed as "ATM at 7/11 @ 48st/McDowell", truncating the date and time part and preserving those for display on request.
Going a step further, allow the possibility to assign a default category or split to such a transaction. If the payee is "CT VCOM HONOR 1965001V" then the default category is a split which assigns any multiple of $20 to ATM:cash and the remainder to ATM:Service fees. Meanwhile, back at Diamond Shamrock, the default category is Automobile:Gasoline. These categories can be edited in the transaction, but are pre-populated on initial download with the predefined amounts.
Call me lazy if you like, but I don't see any point in buying a
dog and barking myself, or running a computer application where I
have to edit the same info over and over and over and over and over
and over again. In the case that a user needs the date and time
displayed for entries from a specific payee - stocks springs to
mind - then you simply don't create a substitution entry for that
item and it is displayed "as is". For the rest of us though, I
really don't care what the store number is for a certain store, I'd
much rather see information that I can relate to!
If I use ATMs at 15 different convenience stores, I want to know which store is which so I can plan to get the lowest service charge, while at the same time I want to be able to track gas stations and compare price per gallon .... hey, can you add in the number of gallons purchased to to arrive at price-per-gallon for a station?
OK, going to close this post before I get too many more ideas! :D
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
1 Posted by Randy on 28 Feb, 2010 02:00 PM
That is kind of the purpose of the transaction acceptance process. How long have you been running the program? The more transactions that go through it, the more possibilities for a correct "categorization" you wind up with. I have been running it for about 9 months now, and it has "learned" the right categorization choices about 75% of the time.
You can do a calculation in almost any amount field such as 9.6 gallons * 2.50 per gallon. It won't retain that, but you could also put it in the memo field.
2 Posted by Ben Spencer on 28 Feb, 2010 06:34 PM
We are actually in the discussion and design stage of a user editable rule based system for processing incoming transactions. Rather like the filter system you might have on your email account. e.g. creating an interface such that users could create rules of the form, if description = x, set description to Y. or if description = A set category to B. and so on.
Sincerely
Ben Spencer
Moneydance Support
3 Posted by Randy on 28 Feb, 2010 06:52 PM
Ben, I kind of have mixed feelings about that.
In theory it sounds great, in practice the descriptions coming in from financial institutions (which they get to some extent from the vendors themselves) are so varied from time to time, that trying to get a high percentage match with a table could be a constant maintenance chore.
If you could allow wild card characters in the table, it would probably match a greater amount of entries and thereby reduce the maintenance.
Also, I wish it could be made optional, if possible. Although we complain a lot about the transaction matching process, my issues with it don't really deal with the percentage of matches, rather the tools we have at our disposal when you have a high volume of uncleared transactions. If you have a large "haystack" you are looking for a needle in, the program doesn't really help keep a visual comparison available, so you can see the needle and the haystack at the same time.
4 Posted by Ben Spencer on 28 Feb, 2010 07:02 PM
I am sure we would allow wild cards in the matching rules.
I know that Sean has plans for the transaction matching interface. I recognize that it is not ideal and we will improve it over time.
Ben
5 Posted by GE on 27 Apr, 2010 03:36 AM
Rule based categorization at import is exactly what I'm looking for. Any idea when you will release it? I'm almost prepared to switch to a competitor for this functionality alone...
6 Posted by dave on 27 Apr, 2010 06:50 AM
One thing I would like to see, and which I briefly mentioned above, is a kind of logic applied to splits for an ATM transaction. Most ATM machines spit out cash in multiples of $20, so divide the ATM transaction by 20 and apply any remainder to the ATM fees rather than simply remembering the last transaction and duplicating it to the cent. This means if I withdraw $20 or $300, the $1.80 - $8.00 (or whatever) remainder is going to be the fee.
I need to categorize these fees separately since my bank refunds them on production of the ATM receipts, so I need to show an outflow of cash to offset the income from the bank refund which means that it is not earned income and therefore not subject to tax calculations.
7 Posted by Angie Rauscher on 28 Apr, 2010 03:55 AM
GE,
I'm sorry to say we don't have a hard release date for this feature. The last time we discussed timelines it seemed like implementation was likely months away. I'm sorry I don't have a more optimistic answer for you.
Dave,
This is an excellent suggestion. I've created a trac ticket, which you can find here. Trac is our feature request and bug reporting system is integrated with our wiki. We invite our users to register and use these systems to help improve Moneydance by bringing bugs to our attention and requesting new features. Users can also vote on tickets, which helps us determine how wide-spread bugs are and which requests have the most demand.
Please let me know if I can be of further assistance,
Angie Rauscher
Moneydance Support
8 Posted by Jesse on 10 Feb, 2011 03:09 AM
Any word on the implementation of the rule based transaction categorization?
9 Posted by Angie Rauscher on 12 Feb, 2011 05:22 AM
Jesse,
No word as of yet, but there will be some exciting improvements coming in the next builds of Moneydance, including new matching features and more flexibility with auto-matching. We'll certainly post on our blog when it's available.
Sorry I don't have more info, but it's definitely part of our discussions,
Angie Rauscher
Moneydance Support
10 Posted by jeffk67 on 04 Jan, 2012 04:48 AM
Hi,
Has this feature been implemented?
11 Posted by Jon Hoover on 06 Jan, 2012 04:26 PM
Hi,
There is a good chance that the next major release of Moneydance will feature a natural language processing algorithm, that converts natural language phrases such as 'today I bought a $6.00 cup of coffee at starbucks' to a transaction. If this goes well for us, it should be easier for us to try and tackle the above process. Unfortunately though, we do not have any current timeline on when we will implement a feature that translates bank descriptions to something more natural.
Sincerely,
Jon Hoover, Moneydance Support
System closed this discussion on 31 Mar, 2015 03:30 PM.