Are there any plans to add a check number column?

Considering humans have been everything from prescriptions in 1st century BCE to 9th century sakks, to the modern system of bills of exchange started in the 13th century (a long time ago), how on earth could ANY budget software even remotely think it could be taken seriously without a built in default method of tracking check numbers????

The answer I found is "We use the memo column to track check numbers", but ironically enough the concept of a memo in the monetary system comes from CHECKS.  So you guys are going to include an afterthought of bills of exchange but not include the most important aspect of them, the identifying number?

Is there any plan to do such a very simply action as add another field to a database and add a check column?  I honestly can't imagine any of my clients taking me seriously if I told them that when we are revamping their budget and getting them back on track with their finances that they wouldn't be tracking check numbers past writing it on the back of a piece of paper as a side note.

I have to write 8-10 checks per month, there's no way I can pay for a system that doesn't have a default tracking method for checks built in, not a side hack that is ironically enough a minor result of checking systems to begin with.

34replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • There is a third party browser extension called Toolkit for YNAB that will allow you to have a check number column for now. I say for now because YNAB could make changes that would prevent the Toolkit from revealing this hidden field.

    Like
  • I use it mostly from my phone.  If it's hidden that tells me it's in the database.  How can a browser extension make a database writable if there's nothing in the page to handle the field being input into the database.  Let alone anything in the backend query to update the row with that field?

    Like
    • TheTabby
    • Just a common cat trying to budget uncommonly well.
    • TheTabby
    • 2 yrs ago
    • Reported - view

    The extension adds an access point to an existing field in the database.  It won't help you with the mobile apps though.

    As for official plans to implement it, the last I saw, there were no such plans, and I believe it went as far as plans to not implement it.  That was propbably a year ago though.

    Like
  • Hey Hot Pink Beat !

    While I don't  think YNAB should be taken any less seriously because it doesn't have a check number column, it's always helpful to know the reason behind a feature request (like you said, you write quite a few checks in a month!) so I appreciate your candor. 

    For a little more background, would you be willing to elaborate on why the memo field isn't sufficient for the check number? I use the memo field for the check number and the payee field for who the check was written to, and I haven't had any issues with reporting, etc! However, I'm pretty simplistic in my check handling/reporting so I would love to know more about where you and your clients are coming from!  Any more explanation of your desired workflow is super helpful, because not only does it help answer the questions below (in italics), but if we decide to build and implement the feature, we have more data to draw from! 😊

    Also, you are more than welcome to submit your feedback via the Feature Request Form! From there it's collected in a database, and just about every day, our Design Team combs through and codes them all, asking questions like Where is this person in their budgeting journey? What problem are they wanting to solve? Then, in regular research cycles they analyze all this collected feedback to plan for what’s up next  in YNAB!

    Like
  • Let me get this straight, there actually is a field for payee but you use the memo field to track the payee?  You just answered all my questions on the future of the organizational skills of the platform.   As for why I don't want to use a memo field to track a data point that belongs in a separate field, it's the same reason I don't use memo for payee when 2 columns over there's a payee field.  Payee is for payee, memo is for memo.  If you want memo to be treated as a notes field, then call it notes or additional info.  Don't try to structure a system to look like a financial tracking system using financial tracking terms that have been in use for longer than any of us have been alive, then say I'm going to redefine it so that people have to use the data from their banks, tax software, other professionals, etc and then say "let's use a different dictionary than everyone else" in how you implement those fields.

    ESPECIALLY if the claim is that the SERVER field is actually there, but can only be accessed by a CLIENT side plugin.  That's the dumbest thing I've ever heard.  Why would a company purposefully obfuscate the functionality of a product unless it's trying to garner support for the plugin arbitrarily through forcing value based on it's usage in a system that already had the functionality.

    If it's in the database, why not use it?  How can a plugin access your database anyway?  That on it's own is pretty disconcerting, but what you are telling me is it's possible to write an plugin from the client side that can manipulate and pull data from your server without needing to have backend access.  In which case my data isn't safe nor is your company secure.

    Thanks for the information.  Unsubbed

    Like 1
      • Jannelle
      • jannelle_ynabsupport
      • 2 yrs ago
      • 1
      • Reported - view

      Hot Pink Beat 

      Sorry for the confusion there! This is what I meant by how I add check transactions in my budget:

       

      The Payee is who the check was written out to, and the memo field is where I put the check number. 

      In our previous platform, YNAB 4, we did have the option to add a check number field, so it's certainly something on our radar! 

       

      As for the Toolkit for YNAB, it's a third party extension, so I'm not sure of the details! I definitely want to address your concerns though, so I can ask a colleague and get back to you. 😊

      Like 1
      • Ben
      • Toolkit for YNAB Designer & Developer
      • furiousfalcon
      • 2 yrs ago
      • 2
      • Best Answer
      • Reported - view

      Hot Pink Beat 

      One of the Toolkit devs here. Just to reiterate -- the Toolkit is not affiliated with or supported by YNAB. It's a browser extension, written primarily for Chrome by YNAB users, which adds styling tweaks and mostly minor features. It may be useful to a lot of people, but we are pretty limited in what we can do -- limited by being a browser extension and only having access to what the browser can "see". We don't (and can't) write directly to the database. We can only access the check field because that data is part of the transaction view, even if it isn't visually present on the frontend, and that data is saved when YNAB saves the transaction.

      It's an option that's available if you use the Toolkit, but it won't be present on the mobile apps. If you're primarily a desktop user, that may be fine... just realize that we depend on YNAB for this field, and they could choose to remove it in the future.

      As to why YNAB technically has built out the field for check info, but hasn't enabled it... I can't speak for YNAB on that subject. I would assume it's pretty common for them to build out and test functionality, and not all of it makes it based on user feedback and the sort of experience they want to offer. Visual space is limited, and it's likely they didn't want to take up extra screen space with a field that a lot of people won't ever use. Checks are a lot less common than they used to be, and I would assume that YNAB figures that the memo field will work for most users. While, no, that number won't be available in its own column, it isn't any less visible in the memo column, and the memo column can be easily searched if needed.

      Like 2
  • I am not as passionate about this as the OP but here's my take.

    Check number is essential because it reconciles the bank's ledger and your ledger.  I would agree with Jannelle that the check number isn't needed for ACH transactions where the person who withdrew or deposited cash is shown in the Payee field.  But most banks that I work show the Payee as "Check #1234".  This could work if you only write a check to a person exactly once for one thing.  Then you could use the memo for "Payee" and continue with your life.

    However, I write checks to the same organization for different reasons.  For example, I may right a check on Sept. 1 to ACME Corp. to purchase roller skates and a rocket with Check #1234.  Sept 4, I write Check #1235 for life insurance.  Sept 7 has two checks 1236 and 1237 for medical bills and for paint, both the exact same amount.  For Sept 7, one is tax-deductible, the other isn't.

    Finally, having a check number field would allow you to monitor your checks.  If I void a check, I void it in my ledger so that if it somehow gets used, I get alerted.

    If not check number field, what about a "Type" Field?  That way I can differentiate between ACH, Check Numbers, etc.

    Like 3
      • WordTenor
      • I have the honor to be your obedient servant
      • WordTenor
      • 2 yrs ago
      • 3
      • Reported - view

      Gray Deer check number #1233 was a donation to the Darwin Awards committee? 😉

      Like 3
  • I'm still baffled why they are being so obstinate about the check number field. I wrote a dozen checks this month.

    Like 2
  • I'll throw my hat in the "we need check number column back" ring.  There are multiple reasons it should still be there:

    • It's just a core banking concept and as another poster mentioned, you're now mixing check# with memo when memo already has its own purpose separate from check# and has for many decades.
       
    • Under the covers YNAB can use check# to positively match transactions downloaded from your bank rather than the end user having to manually look at a memo in their entry, find the downloaded transaction that has payee "Check #1234" that matches the memo, then checkmark it and your own entry that has the REAL payee and hit match....  that's a lot of steps when YNAB technically has everything it needs (assuming you expose check# field again) to make the match and we could then do this with one click.

    As a software developer myself, I can tell you this is all about UX and you lose user adoption when you make things unnecessarily cumbersome.  More clicks == frustrated users.

    Not to mention that I spent about 5 minutes clicking all over YNAB4 to figure out where the option was to unhide the check# column only to end up googling and finding out there isn't one.  YNAB3 had it so I was expecting YNAB4 to have it as well.

    Like 5
      • Paul W.
      • pdub
      • 2 yrs ago
      • Reported - view

      nolesrule Ah, good to know.  I was using online version... I wasn't aware you could get YNAB4 on desktop, I thought that was only YNAB3.

      But that just shows even more confusion. :)

      Like
      • jenmas
      • jenmas
      • 2 yrs ago
      • Reported - view

      Paul W. YNAB4 was not online. It was software that you paid for once and downloaded to as many devices as you liked. The software subscription (originally available monthly or annually, now only annually) now just called YNAB that is web accessible was launched at the end of 2015. Both had mobile apps. 

      Like
      • Paul W.
      • pdub
      • 2 yrs ago
      • Reported - view

      jenmas ok my terminology was incorrect, I apologize.  That doesn’t change what the complaint is about. 

      Like
      • nolesrule
      • YNAB4 Evangelist
      • nolesrule
      • 2 yrs ago
      • 2
      • Reported - view

      Paul W. You are right. It doesn't change the content of your complaint. jenmas and I were just trying to provide clarity for anyone else who stumbles on this discussion.

      And i agree with you on the subject matter of the check number field. I still write 4 to 5 checks a month.

      Like 2
      • bevocat
      • Sometimes, It Just Sucks to Be You
      • bevocat
      • 2 yrs ago
      • 1
      • Reported - view

      nolesrule If I need a check, I'm probably getting a temp one from my credit union or having them send a cashier's check on my behalf, but even I feel like there's no reason in the world they can't have a toggle for show/hide check # column if they're that concerned about screen real estate.

      Like 1
      • nolesrule
      • YNAB4 Evangelist
      • nolesrule
      • 2 yrs ago
      • 2
      • Reported - view

      bevocat I mail checks via bank billpay all the time. But there are just some things where I have to directly hand over a physical check because of the other party. Most of them involve school fundraisers or trips, girl scouts and our fortnightly cleaning service. They accept cash or checks, but I'm not going risk lost cash.

      I actually am not a fan of the bank billpay physical check policy because the checks are debited from my account immediately, not when they are cashed or deposited. So if a billpay check is lost, I have to wait for the bank to expire it before I get my money back. This has happened a couple of times.

      Like 2
  • If ynab is ever convinced to add the check number, please make it optional like it was in ynab 4.  I don't want this meaningless field to take up my screen.  And yes I write a dozen or so checks a month.  

    Like
      • nolesrule
      • YNAB4 Evangelist
      • nolesrule
      • 2 yrs ago
      • 2
      • Reported - view

      Herman I agree that it should be an optionally visible field. If the toolkit can manage making it optionally visible, YNAB should be able to as well.

      Like 2
      • Patzer
      • Retired at age 60. Thank you, YNAB!
      • Patzer
      • 2 yrs ago
      • 1
      • Reported - view

      nolesrule From a programming standpoint, yes.  From a cultural standpoint, there seems to great resistance in the YNAB organization to making anything optional.  Either it's part of their system, or it isn't.

      Like 1
  • +1 to this feature.  The Memo field should be reserved for non-essential notes about what the payment was for instead of reconciliation information like check numbers.  Thx.

    Like 2
  • I also support adding a check number field to the user interface.  Without this "feature" I will not pay for or use YNAB Web. 

    For support to advise people to use a 3rd party browser add-on for important data seems silly and bad advice.  

    I have been using ClearCheckbook  (yes the paid for version) for over a year and it supports check #s, which are still very popular with banks and companies.  I'd be happy to take another look at the web version if and when it supports check #s as a first class data value, not a memo or note or ...

    Like 2
  • Adding my voice to the plea for check numbers. My bank doesn't list a payee at all, just the check number and amount. So your software doesn't recognize that the downloaded transaction is the same as my manually entered transaction with the check number in the "memo" field. So I have to accept a duplicated transaction, then go back and delete one of them or merge them. What a pain!

    Like 2
      • Vibrant
      • No more counting dollars, we'll be counting stars
      • vibrant
      • 1 yr ago
      • 1
      • Reported - view

      Katrina YNAB doesn't look at payees when importing at all. It matches based on exact dollar amount within a 10-day window.

      Like 1
    • Katrina Thanks for adding your thoughts! If you’d like to submit this idea for consideration to our product team, please submit a Feature Request. You can manually match an imported transaction with one you entered, so you won't need to delete the extra transaction. The matching logic uses the date and amount, as Vibrant mentioned.

      When an imported transaction is matched with a manually entered transaction, YNAB has to decide which data to keep in each, but the others aren't criterion for matching. The information you've entered for date, payee and memo is kept, and the amount is from the bank. Let me know if you have any questions!

      Like
      • Katrina
      • Cyan_Gazelle.8
      • 1 yr ago
      • 2
      • Reported - view

        Vibrant , I find that utterly baffling. Keep in mind that the software was coded by a person. Some person made the decision to ignore check numbers (an identifier that is unique and specific to only one transaction) and base the match only on amount and a fairly wide range of dates. Why would anyone think that was an improvement over check numbers? 

      Like 2
      • Katrina
      • Cyan_Gazelle.8
      • 1 yr ago
      • 2
      • Reported - view

      Nicole , thanks. But that's exactly my point. I can "manually" match the transactions. But if the software used check numbers, it could match the transaction itself, and I wouldn't have to go back and do it myself manually.

      Not to mention ... how do I even know for sure which transaction is which since the transaction YNAB downloaded from the bank lists only the amount? The 10-day window is useless with checks because the receiver often doesn't get it deposited within ten days. So I end up having to log onto the bank and looking at the image of the check to see who the payee is so that I can match it. 

      And all that extra work would have been completely unneeded if only you included the check numbers.

      Like 2
      • JonathanS
      • Khaki_Android
      • 1 yr ago
      • Reported - view

      Katrina

      EXACTLY!  Their "super-slick syncing system" SUCKS when it  comes to checks: it just makes YNAB more cumbersome and a time suck.  My spouse keeps wondering why we have all these payments to the same person (no I'm not paying someone off! ;-)  But seriously, every check transaction gets changed to the same name AND my bank only uses check number to indicate payment!  So I have to make sure to enter each check manually THEN delete/reject imported checks THEN change the manual transaction to "cleared", THEN when reconciling try to remember which check cleared and which ones have not!  SO frustrating! .... Please, YNAB, help me understand why!

      Like
      • monkeyhanger
      • No animals were harmed
      • monkeyhanger.1
      • 1 yr ago
      • Reported - view

      JonathanS If it was a UK/Europe based software I would understand. The vast majority of people here don't use cheques any more so I haven't really understood why people were getting so het up about this before. 

      From a few posts recently, I've been made aware that cheques are still incredibly widely used in the US including for interbank payments. If that's the only identifier (or a key identifier) I can understand people's frustration particularly if they're using direct import.

      Like
    • Hi Katrina JonathanS and monkeyhanger !

      Currently, the matching logic is based on date and amount - every transaction that imports from your bank will have at least that information, so YNAB knows what to look for. Check numbers are not an additional and separate field in most file imports, so banks will add them as the transaction description. This can import as the Payee, but file types and bank handling differ. Without an industry standard for this information, and the vast array of Payee possibilities (such as Store 1, Store1, Store-1, etc), we don't include the Payee in the matching logic. 

      We recommend entering checks manually in your budget - that way they're accounted for and will match when the time comes. Manually entering transactions keeps your account up to date and prevents any lag caused by bank importing.

      Like
      • monkeyhanger
      • No animals were harmed
      • monkeyhanger.1
      • 1 yr ago
      • Reported - view

      Faness We don't use cheques here and everything is manual entry for me. I was merely saying that I now understand why the US folk comment on cheques (here and on other threads) so often. I hadn't realised until recently that cheques were still a fundamental part of the US system. In the UK, very few people under 80 still use cheques. They tried to abolish them but there was an uproar from old folk so they're just being left to phase out.

      Like
    • @Vibrant  said "it matches based on exact dollar amount within a 10-day window" 

      Which is EXACTLY why I need a check number field. I make transactions of the exact same amount to different payees frequently and often within the  same 10 days.

      Like 1
  • I'm adding my two cents worth so maybe YNAB will listen.  I just tried YNAB WEB and have decided that not having a check column is a no-go for me.   Also, I know it's off topic, but the way YNAB handles future dated transactions is also a show stopper for me.   So, YNAB Web, thanks, but no thanks.

    Like
Like3 Follow
  • Status Answered
  • 3 Likes
  • 1 yr agoLast active
  • 34Replies
  • 1539Views
  • 23 Following