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.
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
- 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
- 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.