# Imported Bank Statements for a single date converts the dates

**URL:** <https://forum.manager.io/t/imported-bank-statements-for-a-single-date-converts-the-dates/14332>\
**Category:** Uncategorized\
**Created:** [February 12, 2018, 11:13pm UTC](https://forum.manager.io/t/imported-bank-statements-for-a-single-date-converts-the-dates/14332 "2018-02-12T23:13:41Z")\
**Posts on this page:** 11\
**Page:** 2

<div class="post-metadata">

**Author:** ![whosat](https://avatars.discourse-cdn.com/v4/letter/w/bcef8e/32.png) [@whosat](https://forum.manager.io/u/whosat)\
**Post date:** [May 24, 2020, 1:04am UTC](https://forum.manager.io/t/imported-bank-statements-for-a-single-date-converts-the-dates/14332/21 "2020-05-24T01:04:19Z")

</div>

Thanks Tut. Very interesting. Yes, QFX works fine.

---

<div class="post-metadata">

**Author:** ![Tut](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.manager.io/tut/32/3286_2.png) [@Tut](https://forum.manager.io/u/Tut)\
**Post date:** [May 24, 2020, 1:57am UTC](https://forum.manager.io/t/imported-bank-statements-for-a-single-date-converts-the-dates/14332/22 "2020-05-24T01:57:48Z")

</div>

> [@Brucanna](#):
>
> No one has ever stated that the programme is using a non-existing format, except for your own introduced red herring.

I beg your pardon, @Brucanna, but you said precisely that, just two posts earlier:

> [@Brucanna](#):
>
> it is clear from your screenshots that Manager has converted DD/MM/YY data into a MM/DD/YY format even though that format is non-existent

My comment was not a red herring. As proven by @whosat’s statement,

> [@whosat](#):
>
> the Summary page does include the notice: “There are 2 transactions dated after 23/05/20 therefore they are not accounted for in this view”.

my diagnosis correctly identified the problem. The change introduced in version 18.1.66 improved the program’s ability to determine dates from ambiguous inputs. But the fact is, no program on the market can always resolve such ambiguities in QIF files. That is a major reason the format has largely been abandoned, including by its creator, Quicken. It simply traces to an era where US standards were more common because other markets had not yet been thoroughly penetrated.

Manager cannot perform magic. Anyone importing QIF bank files will always need to check for date ambiguities and edit them manually, if wrong. On that basis, I have removed this topic from the bugs category.

---

<div class="post-metadata">

**Author:** ![Brucanna](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.manager.io/brucanna/32/1960_2.png) [@Brucanna](https://forum.manager.io/u/Brucanna)\
**Post date:** [May 24, 2020, 2:34pm UTC](https://forum.manager.io/t/imported-bank-statements-for-a-single-date-converts-the-dates/14332/23 "2020-05-24T14:34:03Z")

</div>

> [@whosat](#):
>
> It is true that the issue could be with the QIF file.

No, as the QIF file contains the correct date data. Manager a downstream processor of that QIF file does an incorrect interpretation, but only when a single date is being imported.

> [@whosat](#):
>
> I’ve been using Manager and importing QIF files . . . . for over four years

That is my exact experience with a multiple of banks. In fact with two of my international financial institutions they only provide the QIF option outside CSV, DAT & PDF regardless how justified others feel in offering their opinion about QIF redundancy.

Financial Institution 1 (being USA based)

 ![0000000 Bug 1](https://us1.discourse-cdn.com/flex019/uploads/manager1/original/3X/c/1/c1290e9ead4a12c7f4baf2dc4d699424bb10a667.jpeg)

Financial Institution 2 (being Europe Based)  
 ![0000000 Bug 1a](https://us1.discourse-cdn.com/flex019/uploads/manager1/original/3X/9/b/9b4f7f805af97ff583079a1e4db33b01aeaac817.jpeg)

@Tut, I just wish you would stick to the facts and not convert, mis interrupt and misconstrue comments to give yourself some unjustified self justification when others disagree with you.

Anyhow, I never realised that when a User has a factually illustrated problem with Manager, that a Moderator needs to do external research to establish if that User’s problem has validity or not. I thought the Moderator’s role was to bring a User’s proven problem to the attention of Developer for their determination. Not to make a personal judgement call on its validity.

Your decision to terminate the “bug” report both contradicts the history of this topic and establishes that you consider yourself to be of a higher standing than the Developer when it comes to deciding upon a User’s factually illustrated problem.

---

<div class="post-metadata">

**Author:** ![Tut](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.manager.io/tut/32/3286_2.png) [@Tut](https://forum.manager.io/u/Tut)\
**Post date:** [May 24, 2020, 4:33pm UTC](https://forum.manager.io/t/imported-bank-statements-for-a-single-date-converts-the-dates/14332/24 "2020-05-24T16:33:18Z")

</div>

> [@Brucanna](#):
>
> the QIF file contains the correct date data.

My point was not that the QIF file contains incorrect data. It does not. In @whosat’s case, it contained ambiguous data that Manager (and other financial programs) cannot resolve due to shortcomings in the QIF standard.

> [@Brucanna](#):
>
> regardless how justified others feel in offering their opinion about QIF redundancy.

I did not say the QIF format was redundant. I said it was antiquated, and it is. Its developer abandoned it years ago. It is available in Manager for imports because some banks do not provide more modern options, primarily because of licensing fees. For internal purposes, they do not need to, because they know how to interpret their own files. For external purposes, they have little incentive to care, because they are not the ones resolving the ambiguities. So why would they invest in changing their software?

Both your illustrations reinforce my point about inadequacy of the QIF standard, such as it is, last codified (sort of) in 1997. Your financial institutions are offering options with specified formats for month, day, and year. These are options implemented by the institutions on their own, not in compliance with the QIF standard. The standard does not require any defined date format, only inclusion of the date, preceded by the letter _D_. Order of elements, number of digits, use of leading zeroes, incorporation of textual or numerical months, and delimiters (or their absence) are left to the discretion of the programmer. Every file produced by one of your banks’ options could, technically, be a compliant QIF file. Yet they would all differ from the others. Quicken’s programmers simply did not look beyond the US market or its MM/DD/YY default format back in 1983 when all this started.

> [@Brucanna](#):
>
> I just wish you would stick to the facts…I never realised that when a User has a factually illustrated problem with Manager, that a Moderator needs to do external research to establish if that User’s problem has validity or not.

I am sticking to the facts, which seem a better basis for answering questions than opinions. When did understanding why a problem occurs become objectionable? The external research you apparently find offensive revealed why this is a problem outside Manager’s control and why a problem previously improved—but never totally eliminated—seemed to recur. That is why I removed the topic from the bugs category. If you know a way to unambiguously establish a date in the first 12 days of a month from a single instance in an undefined, numerical format, please share it. Financial programmers around the world will be grateful. Better yet, patent it.

My research also identified why @whosat might continue to encounter the same problem in similar situations. That led me to suggest alternate file formats for imports to Manager, which turned out to work. Surely that is a role for moderators.

---

<div class="post-metadata">

**Author:** ![whosat](https://avatars.discourse-cdn.com/v4/letter/w/bcef8e/32.png) [@whosat](https://forum.manager.io/u/whosat)\
**Post date:** [May 25, 2020, 2:46am UTC](https://forum.manager.io/t/imported-bank-statements-for-a-single-date-converts-the-dates/14332/25 "2020-05-25T02:46:52Z")

</div>

You folks seem to get very emotional about all this. I really have appreciated the dedication and effort that both of you have put into this forum over the years. Recently it seems to have become a slightly less amicable space. Please relax a little.

It appears to me that the ambiguity in the QIF file exists because the file doesn’t specify what date format it is using. Manager has to decide what to do about that ambiguity, and it appears that (when the format is ambiguous) Manager assumes that the QIF file is using a MM/DD/YY format. That might be reasonable if that is the format is used by most financial institutions when generating a QIF file. If many financial institutions actually export QIF files in a DD/MM/YY format, perhaps the developer could consider either:

1. revising Manager’s assumptions to assume the format is DD/MM/YY
2. OR ask the user to select the date format before importing
3. OR base the assumption on the date format selected in Manager preferences.

Whether it is a bug or not, I think there is potential for the software to better handle the ambiguity, rather than just resign to QIF files importing incorrectly. However, it is a very minor issue that has not caused any huge problems for me and I have a happy solution. So please don’t lose sleep over it!  
All the best.

---

<div class="post-metadata">

**Author:** ![Patch](https://avatars.discourse-cdn.com/v4/letter/p/a183cd/32.png) [@Patch](https://forum.manager.io/u/Patch)\
**Post date:** [May 25, 2020, 3:34am UTC](https://forum.manager.io/t/imported-bank-statements-for-a-single-date-converts-the-dates/14332/26 "2020-05-25T03:34:16Z")

</div>

> [@whosat](#):
>
> - OR ask the user to select the date format before importing
> - OR base the assumption on the date format selected in Manager preferences.

Agree.  
I would describe it as an idea.  
My preference would be to allow the user to specify (somewhere) and if a date is encountered inconsistent with the user selected format, report an error.

The same logic could be applied to

- csv
- Decimal separators “.” or “,”

Although for me personally it makes no difference as I can avoid both with my bank imports.

PS I agree the atmosphere does get more tense than ideal at times. Perhaps we should all put more emphases on describing a “better” solution rather than picking holes in someone else’s ideas.

---

<div class="post-metadata">

**Author:** ![Tut](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.manager.io/tut/32/3286_2.png) [@Tut](https://forum.manager.io/u/Tut)\
**Post date:** [May 25, 2020, 4:17am UTC](https://forum.manager.io/t/imported-bank-statements-for-a-single-date-converts-the-dates/14332/27 "2020-05-25T04:17:58Z")

</div>

I doubt resolution of date ambiguities in QIF files is entirely up to Manager’s developer. I suspect at least part of the functionality comes from a library of software developed by others. Various parsing routines exist to attempt to resolve this problem. It is much easier when there are multiple dates and some inference can be drawn from context. The difficulty arises when only one ambiguous date is present. I don’t know precisely the algorithm Manager uses, but it is possible attempts to discern the format actually make things worse in some situations, especially when a bank’s transaction order is irregular. It is important to understand the software is attempting to guess information that is literally not contained in the QIF file. Sometimes, it guesses wrongly.

The [Guide](https://www.manager.io/guides/9240) about bank imports has always contained cautionary statements about imperfect imports and the need to verify and, if necessary, manually edit transactions. As a result of this discussion, it has been modified to draw more particular attention to potential date ambiguities, not only for month-day reversal, but also for identification of year. These challenges can exist with other formats, too, particularly when banks do not follow more modern standards well.

---

<div class="post-metadata">

**Author:** ![Patch](https://avatars.discourse-cdn.com/v4/letter/p/a183cd/32.png) [@Patch](https://forum.manager.io/u/Patch)\
**Post date:** [May 25, 2020, 5:38am UTC](https://forum.manager.io/t/imported-bank-statements-for-a-single-date-converts-the-dates/14332/28 "2020-05-25T05:38:18Z")

</div>

> [@Tut](#):
>
> software is attempting to guess information that is literally not contained in the QIF file

We agree.  
A solution is for the software to not try to guess at all and instead abide by a user specified format as @whosat suggested.  
That is the solution adopted by most other programs with an international market such as spread sheets

---

<div class="post-metadata">

**Author:** ![generalegend](https://avatars.discourse-cdn.com/v4/letter/g/ac8455/32.png) [@generalegend](https://forum.manager.io/u/generalegend)\
**Post date:** [May 25, 2020, 6:16am UTC](https://forum.manager.io/t/imported-bank-statements-for-a-single-date-converts-the-dates/14332/29 "2020-05-25T06:16:37Z")

</div>

I would suggest that a solution would be to add a field to the “Bank Rules” that enables the user to specify the date format of the import file for each bank.

The initial file import may be guesswork, but this could be adjusted after the first file import.

---

<div class="post-metadata">

**Author:** ![Tut](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.manager.io/tut/32/3286_2.png) [@Tut](https://forum.manager.io/u/Tut)\
**Post date:** [May 25, 2020, 12:46pm UTC](https://forum.manager.io/t/imported-bank-statements-for-a-single-date-converts-the-dates/14332/30 "2020-05-25T12:46:07Z")

</div>

> [@Patch](#):
>
> A solution is for the software to not try to guess at all and instead abide by a user specified format

That may sound simple. But I suspect there would still be trouble, considering:

- Users will (rightly) believe they have already specified a date format. Setting additional preferences would require understanding (1) the format used by the bank, (2) how to override it, and (3) when the override applies.
- Exported formats may not match what users are seeing on their bank’s screens, so there may be no way of easily determining the first parameter above from the bank’s web site.
- Some users will not know how or wish to examine content of an export file, let alone edit it if necessary. And editing may be necessary if the bank uses some form of hybrid text/numerical date format or forgoes delimiters. Remember, there is no requirement that banks choose from among date formats supported by Manager.
- Few will be able to find, understand, or apply export standard documentation. So export files may seem like gibberish, even if the user is willing to examine them.

All these things can apply not only to QIF files, but others as well. This is why parsing algorithms exist. Manager’s philosophy seems to be to relieve users of the burden of figuring it all out themselves to the extent possible.

---

<div class="post-metadata">

**Author:** ![Ealfardan](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.manager.io/ealfardan/32/63166_2.png) [@Ealfardan](https://forum.manager.io/u/Ealfardan)\
**Post date:** [January 18, 2023, 2:55pm UTC](https://forum.manager.io/t/imported-bank-statements-for-a-single-date-converts-the-dates/14332/31 "2023-01-18T14:55:27Z")

</div>

Closed on January 18, 2023, 2:55pm UTC



[Previous page](https://forum.manager.io/t/imported-bank-statements-for-a-single-date-converts-the-dates/14332.md?page=1)
