Hello @andrei.borromeo 

To my understanding, your posting control setting should be changed. IP19 and PP36 should be distinguished. Basically, system reverse original postings (IP17/IP19) when matching advance invoice with advance payment. Once it is matched, a new transaction line with PP36 posting type using actual current rate.

Therefore, I would recommend you split the accounts.

IP19 - Unpaid customer advance invoice account (e.g. 2300)

PP36 - Customer payment in advance account (e.g.2310)

Hope this helps

Hello @Furkan Zengin , thank you for your reply.

Even if I change the PP36 account to a different one (say 2310), the 167,402.52 is still booked there. The FX gain on the payment of 1,644.18 is within that number and isn’t separated out to hit an FX gain/loss account. In other words, the gain doesn’t hit an income statement account. There is a realized gain of 1,644.18 so it should be posted to an income statement account in the period of the payment. 

Or perhaps I am missing something?

Hello @Furkan Zengin 

I think there is misunderstanding of the functionality. What IFS basically does, reverse transactions from advance invoice (IP17/IP19) and create a new ledger transaction (PP36) for advance payment. So actually there is no matching/offsetting between IP19/PP36 ledger transactions.

You may get a currency difference only when you match advance payment with a final customer invoice.

@Furkan Zengin 

So are you saying that IFS is unable to recognize gain/losses on payments on advanced invoices unless it is the final customer invoice? Therefore, such gains/losses will sit in a balance sheet account and the cumulative gain/loss will be recognized at the end?

Hi @andrei.borromeo 

I would not call this IFS is unable to recognize. Rather, this is how the functionality is working. And to me it should be the way it is working. What I understand from an advance invoice, it is a reference record that shows me what to be paid in advance for a customer. 

There is no gain either loss after paying an advance invoice. Therefore it is not stored in balance sheet. A realized FX gain/loss transactions are regulated with PP12/PP13 posting types (tax transactions are not considered for this statement). In your case you only reverse advance invoice record with its original values (IP17.IP19) and create a new record advance payment record (PP36). 

As I stated in previous post, IP19 and PP36 is not offset each other. Rather when advance invoice is paid then IP19 creates a new transaction generating a PP36 transaction.

Hope this is clear

Thanks @Furkan Zengin  . I think I see what you are saying. Seems like the way we are handling billing is not ideal. When we first implemented IFS, we ran into a number of issues which was likely why we used advanced billing. Normally, we would bill depending on the billing agreement. For example, a project can have the following billing terms:

• 60% on PO placement
• 30% on final acceptance
• 10% on shipment

Billing terms can be wildly different, so we need to be able to just bill on the order in chunks or instalments. Do you have an idea on what would be the most appropriate way to bill in this situation in IFS? Staged billing perhaps? Or is there something else?