Re: migration to sql-ledger

Hi Peeter,

Thanks for taking the time to reply!

Now, I'm not sure if I'm going to sound condescending or ridiculing you. I'll assure you, I'm not; it's merely me trying to understand the general accounting processes and your use of the software.

So I explain why we need to change invoices... there are many reasons...

Let's start from big one:
Accountants are perfectionist. I have seen many very stressed out accountants, almost burned out, who use software where they can't make changes. Every mistake is visible and reminds itself to them and also their clients / bosses, who ask about those mistakes as they see these as well.

Ok. Well, there's a very good answer they can give their bosses, I would say. You provided it elsewhere: making errors is human and "life happened".

When we moved over to first SQL-Ledger and then LedgerSMB, this was the big relief and accountants are much more relaxed and happy persons because they know it's ok to make mistakes and fix them. And the best... nobody knows that there even was a mistake.

But this is exactly the problem: sometimes an edit is a mistake, sometimes it's something that needs glossing over in other ways. The software won't know the difference. However, with appropriate comments in the transactions, any auditor/boss/colleague can understand the reason for the corrections. As a software engineer, I understand where they're comming from: I hate it when people find bugs in my software.

Practical reasons:
Clients change their minds about order size, products, ask for additional discounts, want different wording for services etc etc.

Well, that's part of "life happening", so, yes, all this shouldn't be impossible to deal with. I very much like the example you gave in a later mail about the real estate rent invoicing. There are multiple tools in LedgerSMB 1.4 to deal with the situation there:

1. If you use batches and the invoices haven't been sent, the entire batch can be deleted with a single push of a button

2. If the invoices have been posted, but not sent: they can simply be voided. That's what voiding an invoice is for: it's to correct an internal failure -- nothing to be sent to whatever tax authority

3. If the invoices have been posted *and* sent, you have two options:

3a. Send a credit invoice *and* a new invoice; this is a lot of work, especially if/when you need to do separate reporting for credit invoices to the tax authorities

3b. Have a single (additional) invoice, crediting the previous invoice and debiting the new amount, resulting in an adjusted amount

Now, I realise that in order to better support your reporting uses to the tax authorities, you want to exclude voided invoices from your reporting, because there's no need to include them in the data delivered to the tax man. That's definitely one of the absolutely required changes I'm getting out of this discussion.

Today I just change the invoice according to their wiches and I do it in LedgerSMB. Then resend.

This is actually the classic example of "How and Why to use a credit invoice" (http://www.paychex.com/articles/finance/how-when-to-use-a-credit-invoice).

With your process, the customer now has 2 documents with different amounts, but with the same number. What happens if they put the one with the high numbers in their books (allowing high tax deductions) while you have the last one in your books (with the low tax numbers to be paid)? Isn't that a reason to start auditing the both of you? This isn't just about high belief in your trust-worthiness of your employees. This is also very much about the tax authorities thinking they might not be receiving what they're entitled to and your ability to explain that to them.

If this would not be possible I would have to use Word or LibreOffice and remake the invoice there as client wants one clear invoice.

Ok. But before we go in that direction, I'm hoping we can come to some common understanding of why the other options have to be rejected as completely unusable.

And yes, clients even want to change invoice receiving company after they have paid it (as private person).

No problem. LedgerSMB supports that by copying the invoice, putting the company on it, reversing the payment on the original invoice and putting it on the new invoice.

While I understand that's a lot of work, it may also not be the best way to the result. What I heard some time ago is that processing invoices in Spain takes a lot of time (sounds a bit like your situation, really). As a result, people tend to send each other orders, pay to the order and only then send invoices as a confirmation of the payment. LedgerSMB supports that really well: you can have as many orders as you want. You can have them changed as often as you want too. The only thing it doesn't have (yet!) is to be able to accept payment to an order (and have it be used as a payment on the final invoice).

Another big one:
I have developed a script for 1.2 version which generates for me .csv file which I upload to Estonian Tax Authorites.

Nice! Maybe you can share that script, so other Estonian users can benefit from it too? I'd happily include it in our tools/utilities directory in the main repository.

It includes invoice information both sales and purchases with partners where we have had more than 1000 eur worth of invoicing in a given month. It must include also credit invoices, so total might be less than 1000.

Ok. So, if you were able to void unsent invoices *and* were able to exclude these from the "1000 euro report", then your reporting problem would be limited. And since we already agreed LedgerSMB should grow an indicator "this transaction has been voided / this transaction is voiding", we're headed in the right direction, not?

There are some other rules to follow as well. It means I cannot have random back and forth invoicing in the system or this report would include them which by the end of day means I would need to do this report manually or check it manually line by line as I cannot upload information about invoices which actually didn't happen.

Ok. This is why I like to think of workflows and requirements rather than system functionalities: system functionalities exist to support requirements and workflows. In the *current* system, there's no way to exclude invoices which were voided. But as has become crystal clear to me, you have a requirement which isn't supported by LedgerSMB at this point: you need to be able to extract a list of /invoices actually sent/. And if we have the "this has been voided" indicator, we can support your reporting workflow.

Estonian Tax Authorites check that both parties declare the same information and it would not match if I have there some voided invoices etc.

Correct. That's why the *voided* invoices should be absolutely filtered out, there's no dispute about that. Absolutely none.

And if all this changing means that inventory is messed up in the end, so be it...

so far I have made once a year on 31st of December a correction into ledger based on the inventory report value and the difference in balance sheet.

So it matches at this point.

That's great and I'm glad it worked for you. However, I think we can agree that you wouldn't be using LedgerSMB today if it wouldn't be able to generate a good balance at the end of the year, unless you would be an inventory-maintaining company. My point being: all types of users expect LedgerSMB to do the correct thing for them. And it should. Which is why I'd rather implement solutions that have a broad likelihood of being mostly acceptable to everybody.

Also from regulatory point of view... we are talking about small / medium companies... trust level between people is very high, so we are not afraid of fraud by employees.

At the moment, there are talks in the EU about ways to prevent VAT declaration fraud. "VAT carousel" it's called and you can get caught in the middle of it, if you're being careless. Now, having good accounting hygiene will help you not getting caught in the middle. E.g. by issuing new invoices instead of re-using existing numbers. This is definitely not only about your own personnel.

Also I have nightly backups and few times a year when somebody really messes up something I restore the old copy and compare... and find the mistake.
>From Estonian Tax Authorities perspective... they have never asked for audit log or something like that.

Just the list of invoices which include VAT, or whats inside cash account. That's pretty much it.

And that's how it's going to stay, or so I hope. But what if you have to prove that you were *not* the source of the VAT fraud that your customers and/or vendors apparently were part of? Then you become part of a criminal investigation for economic delinquencies and you need *very* good accounting to prove that the source wasn't you. Not practical accounting, no, fool-proof accounting.

Banks want balance sheets and income statements. Nobody really cares how many mistakes there were or how they got corrected.

True. Up to the moment where you hope never to end up: in a fraud investigation due to taxes/vat/etc.

I understand this might not be the case in all countries, but we need a stress free working environment which is flexible and allows correction of everything as needed.

I'm wondering what to say to this remark. It feels like you're telling me I'm not cooperative enough, yet I feel like I'm completely respectful for your position and openly discussing your requirements with you to determine a fit with current LedgerSMB functionalities and the options I see for the future.

Before using SQL-Ledger / LedgerSMB I used HansaWorld and back then there was no way to correct changes... only way was to make a text backup copy and then search from there where the mistake is and correct and then reimport the backup copy... with bigger database it toke like a day or more... and I had to do it couple of times. I had enough, that's why we changed.

If that were the only way to deal with it, sure, I would have changed too. No doubt.

Nowadays it's much easier with HansaWorld as well because I can give changing rights to a specific user who can open old documents, change them and close them. Yes this person needs to know what he or she is doing and correct manually some other things as well, so everything balances but once You learn what needs to be done, it's doable.

Ok.

I hope you can see from the above that I'm taking your problem seriously and that I'm seriously trying to find a solution together with you, within the bounds of what is deemed acceptable in the world of accounting. We want to support your processes the best way we can and to do so, we really need to know all there is to know about your processes and reporting requirements. Thank you for taking the time to write up that description for me.

Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.

Robust and Flexible. No vendor lock-in.