Cash Accounting for UK VAT (Page 1 of 2)

Hi,
Regarding the three month reporting period this can be set in Company setup.

You could change the report for VAT, rep709.php. You should include the remainder of the records (cust invoices and supp invoices) and if they are not 0 they should not be included. Something like that, but maybe somebody can help here.

/Joe

We have an active UK guy on-board. Mr kerrsmith. Maybe he sees this topic and have the guts to produce such a module.

/joe

Hi,

...just wondering if anything was (or is being!) done on the "Cash Rcts/Payments" mechanism for VAT reporting...

If I can help in any way, I'll be very glad to. But... I came across FA for the first time only yesterday, and downloaded and installed it, and it's really very good. I'm a programmer, but, obviously, would need to spend some time getting my head around FA, and the tables, and their relationships, etc.

For the VAT tweaks, the first step would be a detailed "spec" of the rules, as they apply to FA. Perhaps we would get away with just building a new report - to extract:
  - A "Starting Date" and "Ending Date"
  - The Balances of all VAT Paid/Refunded - as at the Starting Date.
  - Any further VAT Payments/Refunds since then (with the Tax folks).
  - The VAT elements of all "outstanding" Drs/Crs Payments and Rcts, and Refunds, Returns, etc, since the start-date.

And these probably need to be split, and summarised, under:
  - Each of the VAT-Rates on Sales
  - Each of the VAT-Rates on Purchases For Resale
  - Each of the VAT-Rates on Purchases NOT For Resale

And this might mean some tweaks with the GL codes...

If the above approach is inadequate, then a more comprehensive approach might be needed, where the Company is set up initially as "VAT on Accruals" or "Cash Accounting VAT", but that sounds like very major surgery!

  - Mike.

Hello, Janusz,

I'm not an Accountant, but I think "Cash Accounting" VAT is a bit more awkward... As Arion stated, the VAT transactions apply only to Actual Receipts from our Customers/Debtors, and to Actual Payments made to our Suppliers. But, we can receive Part-Payments and Payments-on-Accounts, Discounted/Agreed Payments, etc... And, similarly, we might make part-payments to our suppliers, and Payments-on-A/c, etc. So, for either of these payments, I think we must decide "which" invoices (Drs or Crs) these payments are against. And, where the payments do not exactly match the balance on the assigned invoice, then we must, somehow, further indicate the amount of the payment against the net goods/services, and the amount against the various VAT elements on the invoice.

Eg: we might have a  Drs Invoice:
  - Goods-A, value 100.00,
  - Goods-B, value 100.00,
  - VAT at 10% on Goods-A, 10.00
  - VAT at 15% on Goods-B, 15.00
  - Total Invoice value: 225.00
And then we get part-payments, spread over a few months, of 50.00, 50.00, 50.00, and a final "settlement" payment of 65.00 (instead of the 75.00 balance-due!). I think we'll have to allocate each payment against a specific Goods-value, and against specific VAT liabilities, and then issue a Credit-Note for the discounted 10.00 (which also includes a VAT element!).

  - Mike.

I don't know if your approach is adequate... I hope someone else can clarify that point!

However, the system will need to assign the relevant VAT-Period to each transaction, and the relevant VAT-Rate.

Example:
  - Suppose Many Invoices are due for payment, spanning various (old) VAT-periods, and various VAT-Rates.
  - One major payment is received, covering many of those invoices.

That payment (VAT-Incl) will need to be allocated against the relevant Invoices, perhaps fully clearing some of them, perhaps partly clearing others, and perhaps still leaving an unallocated credit balance on the payment (which must be allocated later against new Invoices, or a refund issued).

For each allocation:
  - the VAT-Rate(s) of the Invoice(s) must be used when building the VAT summaries
  - the VAT-Period of the Receipt must be assigned.

Also, I think that some VAT jurisdictions permit "Cash based" VAT returns only on Debtors Payments (eg, a shop). For the Payables, VAT returns still apply on an Invoiced/Accrual basis.

  - Mike

Hi, Roy,

Yep, that sounds correct to me.

Yep...

Agreed also. (I'm in Ireland... "same difference"!).

Except, Arion's first post here mentioned that, for "Cash Accounting" VAT reporting, VAT was claimable on Purchases only when the payment was made to the supplier. I think (but I should check!) that that rule does not apply here - I think VAT on purchases applies to the Invoices (just like normal Accrual VAT accounting).

I'm a (very old) programmer, and NOT an accountant, and also a TOTAL newbie to FA.

Even where NO VAT applies (ie. exempt, zero-rate, etc), I'm pretty sure you'll still need the GL accounts, to account for the NET/GROSS amounts of transactions that fall under these categories.

Agree totally!

  - Mike

Hi again, Janusz,

Great!

If it's of any use to any of you, I'll be delighted to help on this matter. Only in recent weeks, I wrote a small add-on module in an A/cs system to AUTOMATICALLY allocate all Drs credits against all the debits (oldest first) and to extract the Cash-Accounting VAT summaries accordingly. However, that approach was "unique", and would not suit FA (IMO).

I agree that the overall "best" approach has to be adopted...

However...

AFAIK, this "Cash-Accounting" option is intended only to assist the trader's cash-flow, and with the monthly VAT returns. In annual A/cs, Mgt A/cs, etc, the VAT analyses still need to be done on the standard Accrual basis. In any case, over time, the Cash-A/c VAT reports end up with the exact same data as the Accrual data, except the timing is different...

So... maybe you should leave the Accrual system in FA exactly "as is", and the only tweaks might be:
  - Maybe have an additional system option: Cash/Accounting reports are needed [Y/N]. If Y, the remaining tweaks would be supported... (If possible, avoid this option in the first place!).
  - On Receivables, encourage the user to fully Allocate each Credit against the relevant Debits.
  - For each DB, it will probably be necessary to note which Credits have been allocated against it. The DATEs on the allocations define the VAT-periods.
  - And, on each Credit, note which DBs it has been allocated against. That identifies the relevant VAT-Rates.
  - Or, maybe a separate "Allocations" table could be maintained, and hooked to the parent DBs and CRs. (I know nothing yet about the FA internals, so perhaps all this allocation support is already in there).
  - Obviously, if transactions are edited, these allocations must be edited accordingly.
  - If the Cash-Accounting VAT also applies to the Payables, the do exactly the same with the CRs and DBs there.
  - Finally, and this might be the only "new" feature to be activated in FA, have a separate "Cash-Accounting" VAT report, to show all the VAT activity as discussed above and in the previous posts here.
  - I think all the current GL A/cs, VAT A/cs, etc, in FA would not be changed in any way - I certainly hope so!!

Mike.

I agree.

Actually, Roy, I'm not! I should look it up - if you have a link, I'd appreciate it. Also, sometimes, the official "specs" of these types of procedures are more legal than technical, and might need some reduction, re-hashing, etc, to facilitate computerisation.

Agreed. Maybe very little work needed in FA...

Me too. I'll gladly knock up a few lines PHP, and/or a few SQL statements, but I'm also totally unfamiliar with the internals, and such a project would need to be directed by someone with an intimate knowledge of FA.

  - Mike

Thanks, Roy.

That paper is excellent. Happily, our posts above tie in extremely well with the official spec. Perhaps we should emphasise the following (mainly for lurkers here!):

1. The "Cash-Accounting" mechanism is permitted (in the UK) on Purchases (Crs/Payables), as well as Sales (Drs/Receivables).

2. There seems to be an exception, on Purchases, regarding some unusual purchases - eg, Imports. See points 5.5 and 5.6. The VAT on these transactions apply at the time of Invoicing. In FA, I assume these types of purchases would need to be tagged separately, and, therefore, treated separately in the VAT reports.

3. Our posts above have not covered the rules and processes involved in Joining the scheme, Leaving the scheme, Re-joining, Insolvency, etc. Presumably, most/all of these would be outside the scope of FA anyway?

4. I didn't see any advice re how best to handle national VAT-Rate changes. This can be traumatic! Maybe best to have VAT-codes, assign a new code to each new Rate, and start using the new code - as appropriate?

5. Auto-allocation of Credits: See point 5.7. I thought the book-keeper might have to manually allocate every credit against the relevant debits. However, 5.7 says otherwise, which greatly simplifies the user's actions, and makes FA EVER more beneficial!! As I mentioned, I already have implemented "Auto-Allocation" code, which we might be able to use in FA. A matter not mentioned in the HMRC spec is, eg, what to do if Invoice-123 is issued, and it's cleared later by Credit-456. Then Inv-123 is withdrawn... and Cr-456 is freed up, to be allocated against other debits. The automatic mechanism covers all this, and always re-allocates the remaining credits against the remaining debits - ALWAYS oldest first (as per 5.7). So, the VAT summaries emerging might show changes for previously closed VAT-periods, in which case the current VAT balances must be adjusted by the VAT Payments/Refunds made to-date, to arrive at the current VAT payable/refundable. (Hope this makes sense!).

6. I would, very respectfully, suggest that the official approach for handling part-payments against invoices with multiple VAT-rates, as per 8.2, is not as good as the mechanism in the above posts. They seem to be calculating/allocating VAT against the VAT-summary on the invoice (I don't know what would happen if they had MULTIPLE non-zero rates in the example!), rather than against the individual line-items - as I suggested. With the line-item approach, the VAT summaries should show all VAT amounts at the exact rates, and this can be useful in auditing, etc. With the HMRC approach (I think!), the VAT summaries might not reflect any of the standard rates. The overall result, obviously, is still exactly the same in both cases.

So... whereto from here!!

  - M.

Paul,

I have done nothing on this matter, nor had any contact with anybody about it - apart from what is in this thread.

As I stated already, I would be very glad to help in any way. However, I've no familiarity with the FA internals.

  - Mike

Hello Mike,

Yes, this is good idea to place all the info on the development wiki. Currently we are more than busy with latest fixes before final 2.3 release, but after it is released we will have more time for cash/accrual VAT implementation. Good news is in the same time I'm involved in implementation of VAT related changes for Polish fiscal rules. As the rules are at least similar throughout EU some of them surely will go to core FA, and will be helpful during other local european VAT implementations.

It is up to you whether you will describe the matter directly on Wiki, or using GoogleDocs. To have write access to the wiki you simply need to log in via forum or wiki interface. I'm not sure about write access rules to specific wiki pages, so if you encounter any problems give me a note.

Thank you for helping us to make FA more friendly for european users .

Janusz

Thanks for Feedback,

I am as Mike. Happy to help (have some PHP skills) but know nothing about FA (apart from whats on this thread).

Paul