in Customer offset , CUPOA and AD offset each other . remaining balance in AD is USD 20
In fourth step it created CUPIA automatically to match against CD invoice created @ final steps
Create AC( advance credit ) for the remaining balance 20
Create CD by reserving / delivering the CO , so the final CD is created for an amount of 100 in a state partly paid posted. ( CUPIA created at step 4/5 offset eachother automatically)
So they need to finally credit USD 20 from the last CD invoice they had raised
Now in the System we can see below invoices exist
> partlypaid AD with remaing USD 20 ( 100- paid 80)
>postedauth AC with amount of 20
>partly paid CD with reaming amount of 20 (CUPIA created for an amount of 80 which match against this)
What i suggested is to
>Offset Remaining AD with AC
>Then raise new Credit invoice for an amount of 20( CR) and then offset with final invoice
but customer reluctant to proceed this method instead they claim that negative CUPIA should be raised at step six, But unless we made a payment CUPIA not raised automatically
Would you kindly advise on how to proceed.
Thanks,
Kanchana
Page 1 / 1
Hi,
In my opinion the steps 3,4,5,6 are not necessary. If you post the customers payment directly against the AD invoice from step 2 you will have a cupia posted automatically and If you create the final invoice from the order the CUPIA will be automatically matched against the final open invoice.
Since advance invoices are usually no commercial invoices but more a letter requesting for a payment they are not part of the balance sheet. Often they are posted to statistcal accounts (AF, AF1, AF2) like this:
If an advance invoice is not fully paid you might want to get rid off the remaining open amount on IP17 and IP19. I would suggest using mixed payment for this and a zero payment line against the invoice also using a write off code to write off the full remaining amount. The write off must be posted against the account setup for IP19. In this case PP17 (Write-Off, Customer Claims) should be posted using control type PC4 (Write off Code) for the newly defined Write off code against account AF2 (same as setup for IP19).
This solution avoids creating additional invoices and cupias and matching these ones. Also you can restrict the amounts and persons being able to use
Kind regards
Ralph
Hi,
@Ralph Gericke, in some countries advance invoices are regular commercial invoices, at least from tax perspective, and full process described by @Kanchana makes sense (treasury creates CUPOA from bank transaction, AR identifies the purpose of payment on the basis of advice from customer and creates an offset).
@Kanchana, what you are suggesting to do is correct. Offsetting remaining AD with AC, during offset approval system will ask you if CUPIA items are to be created or not. CUPIA items are normally created for received/issued cash only, not just on invoice creation. In this particular case you can select not to create them, as then you would need to offset manually two CUPIAs against each other.
For the remaining 20 on CD invoice - if you do not expect your customer to pay this amount, credit note is better way, I think - it requires you to indicate purpose of the variance (rebate in price or quantity correction, etc.), ensures proper revenue account is corrected and gives more data for sales analysis. You may as well follow write-off process suggested by @Ralph Gericke, but I would do it only if amount is not material.
Thanks Ralph and Adam,appreciate your responses . I will consider these points and check the best possible way of handling this
This is very interesting and so informative, thank you Ralph and Adam - I am trying to sort out a similar issue and this completely fits the brief! Off to test it and send to the finance team for their approval.
Kind Regards
Paula
We have the same issue. If the customer pays an Advance Invoice but there is a bank fee of say $10, we write off the $10 in the mixed payment on the line to write off code BC for bank charges. The customer AD invoice is now paid in full. However, there is a glitch. IFS will not read the invoice as paid in full and therefore the order will block. The only solution we’ve found is to enter a separate line for the write off. More work. I think this is a bug.
