Payment rules not correctly allocating payments to expense claim payers

What is the format of these output files from the converter? Your example does not look recognizable. Those three rows are also inconsistent in content and format from row to row. If that is what you are importing, I am amazed you are able to import anything at all.

This output is corresponding to this: Import bank statements | Manager

@gunnar.michelson, that Guide describes a process, not a format. My question was what format the output file from your converter is. In other words, is it .xml or .csv or something else?

If the file is not in one of the defined formats mentioned in the Guide, importing will not work. And if the format is .csv, Manager will be dealing with very limited information. Even if your output files are in a supposedly supported format, they may not contain necessary information. That is because banks often do not follow standards closely when exporting files. (And some formats themselves are very poorly specified—even being technically obsolete.)

@Tut in Estonia we dont have so old standards: *.qif, *.ofx, , *.qfx, *.qbo, *.sta, *.swi, *.940, *.iif

Here is a link for the Estonian XML standard: XML B2C & C2B communication messages — Estonian Banking Association

As you know, Manager is not supporting XML files, so we made very simple converter. If there would be some other technical information, i would to organise something much better.

Unless your converter outputs one of the specified file formats, importing bank statements will never work for you.

I am removing this topic from the bugs category, because you are not adhering to mandatory requirements. It is not a bug when Manager will not do what the program itself tells you it cannot do.

Really!? So please then provide information what kind of requirements there are!
At the moment you are just ignoring and not providing any solution, only talking and talking. I would to ask then, what kind of forum is that?

Also @Joe91 told it thats a bug.

I beg to differ.

I have a cvs file which follows the format given in the guide

Date,Reference,Description,Amount
19/07/2021,Claim 1,Claim 1,-50
17/07/2021,Claim 2,Claim 2,-750

When I import it using the payment rules


and

I get the following
image
but when I import

It seems to select the correct account but not the sub-account

So I do not think it is a problem of the format but rather the selection of the account and sub-account in the bank rule not being recognised correctly or not being applied correctly

2 Likes

OK. So this topic is still in the bugs category. That is based on @Joe91’s complete illustration with a file format the program supports.

Those are clearly explained in the Guide. @gunnar.michelson, you have resisted my request to specify your file format twice. And the sample you showed did not conform to anything Manager will handle. As a moderator, I cannot classify behavior as a bug on that basis. You did not show that the program failed to do what it was supposed to do.

I am sorry you feel that way. But you are not being ignored. This topic has gone on for 28 posts as @eko, @Joe91, and I tried to help. That was made more difficult by a forum software issue and the lack of precise information. When @Joe91 provided a comprehensive example using a file format the program supports, the behavior could be seen to be deficient.

Thats not true! I have copied for you the file format. Here its again:

And these 3 lines follow the 1: 1 Manager rules. Look please again! Even if you compare @Joe91 's message, it matches:

I really didn’t expect to have to rewrite the whole story every time. In my very first post, I brought up screenshots that showed exactly the problem. Logically, if another import works and only part of it doesn’t work, then it can only be a bug in the program, otherwise it wouldn’t be possible to import anything at all!

Yes, big thanks for @Joe91! @Joe91 had to tell you TWICE that it is a bug. If I add my post here, it will be THREE times! I’m not a first day user and just because I don’t post on a forum every day doesn’t mean I can’t. I have been using the Manager on a daily basis since 2015.

In Tut’s defense, I will say that I found the opening posts a little bit clustered because of the different language in the description and account names. This was distracting when I was trying to understand what had or had not been matched.

Also, I never use Bank Import so was not familiar with the process and only when I sat down and tried it using my simple example did I see what was wrong.

There is also the distraction of using the Expense Claims feature in a “non-standard” way which adds another distraction.

Sometimes users use Manager in ways that are not obvious and can appear surprising even to seasoned users

No, you transcribed part (or all) of the file. You never specified its format. In other words, what file extension does it have?

Not true. Depending on how various file formats are parsed, the program may try to extract what it can. But failing, when encountering a format explicitly not covered, cannot be considered a bug. As I wrote earlier, I am amazed you got anything.

But he illustrated it only once. His first mention quickly moved on to discussion of expense claim philosophy. If you review the entire thread, you will see that I first put this into bugs as soon as I was able to see your screen shots. That was post #15. (Prior to that, your terminology led us astray from what turned out to be the actual issue.)

I announced that I would remove the topic from bugs after extensive exchanges with you finally revealed you apparently have your own special format for statements. (You still have not said what it is. You have only defended it.) At that time, I explained why I could not classify the behavior as a bug based on your description of the problem. As soon as @Joe91 illustrated the problem, I announced I would leave the topic in bugs.

Please understand that you are not being persecuted. Moderators can only move topics to the bugs category when the reported behavior can be replicated and it deviates from expected design performance. You never presented a clear story that was happening.

By the way, the link you provided in post #24 is not to any statement standard. It was possible to drill down through levels of hyperlinks to another document that included statement standards, however. That document does not remotely match the format of the example data you provided. And it does not conform to any of the formats Manager understands. If that is what your bank provides, that serves as another example of why bank statement imports are sometimes impossible. Banks simply have no incentive to provide customers with information in forms that take the bank out of the loop.

Thats okey! Cos you need to be an accountant to understand all the possibilities and issues.
Example: Manager logic here is: Employee buy something and the company compensate it (pay back)
Example2: Company make to the employee prepayment example 500 euro and now the employee buy something
Example3: Company gives to the employee business credit card (or whatever) and now the employee buy something

By all this examples are actually different situations. The question stays, how many documents do you have. If you have only 10 documents per month, then its very easy to separate them. But if you have 100+ documents, then you need implement only one rule, so as I do. Why? Cos you can save a lot of time and perhaps taxes.

Example 3 is not an expense claim. If the card is issued to the business, it should be set up as a bank account in Manager and its use involves a receipt, not an expense claim.

This was a bug. Fixed in the latest version (21.7.30)

You are wrong!
Payment with a business bank card shows only that you have paid some money to someone and nothing else. Its like you have made a regular bank transfer to the supplier and nothing more.

Correct transaction is by the card payment:
Credit Bank
Debit Supplier or Expense Claims

After you book a bill then the correct transaction in the books are:
Debit Costs
Credit Supplier od Expense Claims

The main reasons here are the content of the economic transaction, accrual accounting and the principle of matching income and expenses to correspond to the period.
Example: your bill date is 31.01.2021 but you bank credits your account on 01.02.2021. So if you book your bill with a date 01.02.2021 then you have made a mistake.

1 Like

More conventionally

  • Employee buys something on company credit card.
  • Purchase invoice is entered when purchased (or ordered).
  • Bank import later indicating invoice payment

Alternatively

  • Employee buys something using petty cash (small amount of companies money taken to shop)
  • payment entered in petty cash account or purchase invoice entered in Manager

Both reported accurately in Manager using cash or accrual based accounting. Neither requires unconventional use of expense claims. Now Manager supports non conventional expense claim use, either approach could be used & comply with accrual or cash reporting obligations.

As I told before, if you have 10-20 bills per month, its easy to manage that. But if you have every month 100+ documents, then you will lose the overview that was paid with the card that was unpaid, etc. In this cases you have implement one fixed rule for all those documents. Cos time is money and you shouldn’t waste it

1 Like

In one case a purchase invoice is entered at the time of purchase, in the other an expense claim. Similar work at the time, similar tracking facilities.
But what ever, Manager has already been changes it is mute now anyhow.

I mistakenly typed receipt when I meant payment. But the rest of my statement was correct. Use of a business bank card to pay for goods or services for the business is not an expense claim. That was my point. Your comments about accrual accounting are not related to that.

And @Patch is correct. Although your initial report of the problem was confusing, and the discussion about what constitutes an expense claim diverted attention from the actual issue, the bug was fixed. I am closing this topic.