Importing Old Transactions

I'm migrating my data to YNAB from CountAbout and am using the API to do so.  I have history going back as far as 2010.

 

However, when I attempt to import old transactions, it returns an error saying "date must not be in the future or over 5 years ago".

 

A couple of questions:

- I can manually create a transaction from more than 5 years ago on the website; why not the API?

- Are there any alternatives for getting historical data imported via the API?

 

I'm currently using the API because the CSV imports don't seem to properly handle transfers, and this gives me more fine-grained tuning when it comes to setting the correct payees and categories.

4replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • Cyan Trumpet We limit future and far-past transaction creation for two primary reasons, one practical, one philosophical:

    1.  As a protection against abuse: Transaction creation includes significant post-processing to match payees and re-calculate roll-up statistics, among other things. When you create transactions via the web UI, you can only do it so quickly. With the API, you can very easily create a bunch of transactions, which if left unchecked, could impact the performance of the rest of the app.

    2. Historic data has limited value: Generally we don't recommend users worry about historic data. A successful budget is forward-looking. Spending hours recreating old budgets and categorizing past spending usually isn’t worth the time. (See Fresh Start for more. )

    That said, you may have specific tax or reporting needs for this data, in which case you're limited to five years in the past.

    Like
  • I see. Thank you.

     

    For protection against abuse, if the expensive part is due to the number of transactions and not the date, then shouldn't the limit be applied on the number of transactions created during a time window, instead of the date of those transactions?  It seems like that would be more systematic protection against abuse as well as permitting a wider set of usage scenarios.

     

    Note that the 5-year restriction doesn't apply to file-based import, and that allows records to be created in bulk.  In my case, file-based import (at least via CSV) doesn't work since it doesn't support import of categories.  (Note: not technically true, I think.  Based on some reading and experimentation, I could import them via CSV, manually fix up auto-categorization rules manually for about 1000 payees, delete the transactions, then import them again to have the auto-categorization rules take effect.  But this seems like an excessive amount of manual work.)

     

    My desire is to have a record of the past for trending analysis and record keeping.  I don't want to have 2 different places for the information.  Maybe it's overboard, but it's a thing I'd like to have :)  It's a large reason I migrated from Mint to CountAbout, and YNAB has a number of compelling features over CountAbout so I'm really looking for a way (even if it means me writing code) to get my data in there.

     

    Thanks for the background. I'll see if I can find a way to make this work for me.

    Like
  • I believe I have found another way to accomplish this.  I've done the following:

    - Updated my code to produce a CSV suitable for import, without the categories.  This allows me to import all of the transactions without date restrictions.

    - Via the API, update the imported transactions to put them in the appropriate categories.

    Like
  • Please don't do this to yourself. Aside from cost/security it's just a really surefire way to cause yourself 1 million ynab headaches. If you need transaction history from 2010, save it as a csv somewhere and refer back when necessary. For YNAB, start with your balances today and your spending today. There is zero benefit to having your old history in the file you're using for your current budget. 

    Like 1
Like Follow
  • 1 yr agoLast active
  • 4Replies
  • 464Views
  • 2 Following