Tax Report on Cash Basis

The Tryton period must match the tax report period. It is the only purpose of the period.

Yes but I don’t see how it can be done differently because we need to create records based on how much an invoice has been paid. But for that we must take a snapshot of the link between payment and invoice at one moment in the period.
But there is the solution:

I mean the period of declaration IRL

Some years ago we did some experiments with taxes applied on payments. Just a short summary: A company can be marked as cash based for a fiscal year. In cash based fiscal years, invoice taxes are collected in tax accounts for undue taxes. On payment the undue taxes where moved to due taxes account. The tax declaration is based on due taxes, only. It is always possible to take a look to the undue accounts for the taxes to expect. You can change the tax method for each fiscal year.

The problem with such design is to define what you call “on payment”. In the basics of accounting this concept doesn’t exist. In Tryton we have used the reconciliation to simulate this but reconciliation can be undone and it doesn’t support partial payment. That’s why my proposal is based on the period closing for me it is the only way to fully support this requirement.

I’m going to add another complication to the tax report on cash basis as you are proposing @ced, on México we need to report tax for advance payments from customers or to suppliers for example if March 31 I got a payment from customer I must pay VAT from that payment on March even I generate the invoice on April 1st.

For me, such advance payments are managed by account_deposit so we have already an invoice.
And also we have:

which also concern invoices from the next period but you have to post it.

In France, advance payments must always be replied with an acquitted invoice so it is somewhat a similar case.

To revive this topic a bit, cash basis is absolutely fundamental in France as, frankly, almost
every company that provides “services” uses it and it is by default as one must specifically
opt to use accrual with a formal declaration to the fiscal authorities.

If a supplier has opted for accrual-basis for services, he must add a specific clause to his invoices mentioning that fact.

NB: and yes, an invoice can actually have mixed taxes, accrual for the goods and cash for services.

What castaf@ mentioned in using 4458 is an age old means to easily support both mixed and pure case basis. I believe this method is used in many many companies.

Luckily, the tax plan already separates sales VAT by goods and services so it is well underway and can easily deal with these two cases, worst case adding the option 'tax accrual-basis for services ’ to the party accounting tab might help out here for the fringe cases.

Here I’d like to interject a problem I’m encountering with the tax codes that probably could/should be considered at the same time.

The use case with construction subcontractors in France where the prime contractor is responsible for liquidating taxes on behalf of his subcontractors, even if they are paid directly by the client.

Here, the subcontractor invoices the prime contractor without VAT (and mentioning ‘autoliquidation’)

The tax declaration for the subcontractor is somewhat easy, when paid, he indicates his invoice amount base as ‘other non taxable operations’.

The prime contractor will, when the subcontractor is paid, declare the subcontractors invoice amount base as ‘other taxable operations’, and will proceed add the invoices tax base to the appropriate VAT rate along with the rest of his proper invoices that are VAT exigible. He will also add the subcontractors invoice VAT amount to his VAT deductions for goods and services paid.
NB: worthwhile to mention that the VAT rate may different for the prime contractor’s client invoice then for the subcontractor’s invoice (e.g. certain renovation projects benefit a reduced VAT rate)

So far so good, but now the wrench thrown in to the mechanism.

Imagine there was an error in the subcontractor’s invoice and a credit note(or correction invoice) is issued to correct this.

VAT declarations in France disallow corrections in the VAT bases, so these corrections must be applied to a special line 21 ‘other deductible VAT (including collected VAT regularisations)’

  • credit note received in same period with payment corrected
    In this case the bases can be corrected directly as nothing was declared ‘yet’

  • credit note received in a subsequent period after payment/VAT declaration
    Then the bases cannot be corrected directly and must wait for regularisation of the payment either by compensation with a following invoice (if appropriate, such as with progress invoicing on a project) or by reimbursement.
    The former can potentially be regularised in the VAT declaration via the bases, but the latter specifically means line 21 needs to receive the amount of the VAT to regularise following reimbursement.
    The worst case, the subcontractor doesn’t repay or goes bankrupt, then it’s treated similarly.
    (BTW this may also apply to unpaid clients invoices not only autoliquidated

Finally, the subcontractors invoice VAT amount needs to be subtracted from the VAT deductions for goods and services paid.

Perhaps it would be better to allow a company to disable tax code moves at least until cash-basis has support as it’s providing completely distorted data at the moment.

So the configuration should be at the tax level.

I think it will be simpler to create the tax lines any way but not linked to any period. And on closing period, we duplicate all the tax lines without period to add the period and change the amount by the invoice paid ratio.

Not sure how you intend to manage this, but in France for example, what castaf said (with respect to 4458xx TVA à régulariser ou en attente) is used as it simplifies much …
not to mention that when the certified accountant comes to control taxes, he or she needs something tangible to ‘contrôle’.

How do you suggest auditing when using these ‘tax lines’?

I do not understand the question.

I start working on the implementation: Issue 7139: Tax Report on Cash Basis - Tryton issue tracker

Indeed I will not be too complicated to create an extra move from the tax account (waiting) to another account based on the tax line updates.

When implementing, I found that it was more efficient to update the tax lines when payments were added to the invoice instead of when closing the period. This is because it is difficult to search for the invoices that have payments updated during the closed period.
So by default the tax ratio the paid invoice is moved to the current period.
I will add a wizard on move line, like the reconciliation, to add a line to an invoice and select the date/period at which this should be registered.

The implementation is ready for testing at Issue 7139: Tax Report on Cash Basis - Tryton issue tracker.
It is a little bit different as the initial design as it follows Tax Report on Cash Basis but the main concepts have not changed.

The supplier case has been improved see Message 38492 - Tryton issue tracker
Now supplier invoice can force some tax groups to be on cash basis.

Okay, that’s the idea.
For clients, when invoicing, one may prefer

  1. putting the tax initially in 4458x TVA à régulariser and upon each payment put the tax paid into 44571x for the period’s VAT declaration (which will then be moved to 44551, typically), or
  2. putting the tax in 44571x directly then only declaring VAT for what is exigible
    (then moving that part to 44551)

For suppliers, it is similar… for the latter case, there may be accounts such as the following
445661 TVA récupérable sur biens et services d’après la facturation
445662 TVA déductible intracommunautaire
445663 TVA récupérable sur biens et services d’après le paiement
445668 TVA déductible (autoliquidée)
plus others if the company wishes to have the basis type accounts split per tax rate.

BTW, for client invoices involving autoliquidation, I hope the case for a ‘base’ without any ‘tax’ amount is managed under cash basis (Opérations non imposables).

Finally, how does the each period tax declaration know what has already been declared or not? A typical case example is a missed payment on a customer-direct paid subcontractor with autoliquidation.
That is, If the accounting move between the payment of the subcontractors invoice and their part of the client invoice is not made in order to [partially] pay both invoices, then it needs to be caught up in the next declaration period, but may be, and typically is, booked in the actual periods accounting wise.
Reconciliation on the move lines in the tax accounts? If so, does this mean that Tryton [can] generate the CAx move resulting from the VAT déclaration?

Feel free to test it.

I do not understand this question. It is clear in the implementation how it is done with the period on tax line.

I do not think it is a typical use case.

I do not understand.

What is CAx?

I hope to be able to test bits of this in the upcoming week(s).

With respect to the period, I was under the impression that closing the period was no longer a requirement… indeed, it is a rather utopic situation, perhaps somewhat unreasonable where there is any volume of supplier/client processing noting that the VAT declaration, for those on a monthly basis (CA3), is usually the 24th of M+1.

Typical case in my example means frequent for any French company doing construction, services or industrial business under public tender, having subcontractors will probably encounter this, as direct-payment is a legal requirement (art 112 Code de Marchés Publics) as well as for those companies with private contracts having delegated payments to the customer for their subcontractors (as opposed to providing a bank guarantee which is not always feasible for small and medium sized companies, which is why it is so common).

CAx is the move constating the period’s revenue (Chiffres d’Affaires) declaration (CA3 == monthly, CA12 annual)
This is all pretty well explained in various places on the internet, not to mention in section IV TVA of Chapter 11 Opérations de Régularisation, Exceptionnelles et Diverses, Lefebvre’s Mémento Comptabilité…

This topic was automatically closed after 14 days. New replies are no longer allowed.