Dynamics 365 Project Operations: Changing the “bill to” customer after invoicing

Tested on:
Project Operations solution version 4.6.0.123 (pre-alpha), F&O 10.0.15.

The Dynamics Community forums had an interesting question about changing the “bill to” customer after invoicing. With a “bill to” customer I mean the customer at the receiving end of an invoice. While this is a pretty frequent requirement (I’ve been in this situation myself many times), there isn’t a simple and easy answer to solve a scenario of changing a “bill to” customer after an invoice has been confirmed. Why is that? It’s because approved time entries with billing activity can’t be recalled and their related approvals can’t be canceled. Entry corrections are also blocked for transactions with billing activity:

There has been some billing activity for all or a few of the entries that you have selected. Approvals cannot be cancelled on these entries. Make sure that your selection only includes entries that have not had any billing activity.

Before we move on and solve the “bill to” customer problem, I want to promote a D365 application idea I’ve created for this feature. Be sure to vote it up here. I also want to give my thanks and kudos to Erik Norell from proMX for explaining some accounting and financial concepts to “a simple CRM guy” like myself. I also want to thank the Product Group for their help.

Changing a”bill to” customer

The example scenario is as follows: An invoice has been confirmed in Dataverse and a Project invoice proposal has been posted in F&O. The goal is to change the “bill to” customer i.e. the recipient of the invoice. First, the original invoice needs to be credited. There are then three different options to achieve the goal of changing the “bill to” customer. The options are:

• The first option is to reverse the existing Unbilled Sales and Cost Actuals that exist after an invoice has been credited. A new Project Contract Line Customer is then set and new Unbilled Sales and Cost Actuals are created and invoiced.
• The second option is to reinvoice the Unbilled Sales Actuals and set Invoice Line Details as Non-Chargeable. The original Unbilled Sales and Cost Actuals are then reversed with Journals. A new Project Contract Line Customer is then set and new Unbilled Sales and Cost Actuals are created and invoiced.
• The third option is to reinvoice the Unbilled Sales Actuals and set Invoice Line Details as Complimentary. The original Unbilled Sales and Cost Actuals are then reversed with Journals. A new Project Contract Line Customer is then set and new Unbilled Sales and Cost Actuals are created and invoiced.

Let’s cover some terminology before moving on as there are differences between Dataverse and F&O:

• An invoice that is created in Dataverse either from the context of an Order or from a batch job based invoice schedule is called a proforma invoice. This is the terminology that docs.microsoft.com uses, however it doesn’t explicitly say proforma invoice anywhere in the Unified Interface. Proforma invoice and invoice are interchangeable in this blog post.
• In Dataverse, proforma invoices are Confirmed instead of posted.
• In Dataverse, proforma invoices are corrected when they are credited.
• In F&O, a Project Operations integration journal is posted.
• In F&O, a Project invoice proposal is posted and a Project invoice is created. These invoices can’t be edited in F&O as invoice correction is done in Dataverse.

Dataverse and F&O after confirming an invoice

Let’s look at Dataverse and F&O on a high level (i.e. we’re not combing through the GL) to see what is created in both systems when an invoice is confirmed. The F&O used is based on the F&O demo DB so all ledger postings are made according to the OOTB “Contoso demo data” setup. Images 1-4 below show a confirmed invoice in Dataverse, Actuals as a result of the confirmed invoice, a Project invoice in F&O (created after a Project invoice proposal is posted), and related voucher transactions.

Dataverse and F&O after correcting an invoice

Next, let’s look at Dataverse and F&O when an invoice has been corrected. Remember that correcting invoices is done in Dataverse. When a corrected invoice is confirmed in Dataverse, the original Actuals are reversed and new Unbilled Sales Actuals are created. In F&O, a new Project Operations integration journal is created. When the integration journal is posted, a new Project invoice proposal with a reversed, negative amount is available for posting.

After a Project invoice proposal for the reversal is posted, transactions need to be settled to set the balance to 0. Otherwise, the transactions may become overdue and go to Collection, which is not the intent. More about settling transactions can be found here on Docs. When transactions have been settled, the invoice correction process is complete. Unbilled Sales Actuals can now be invoiced again by setting them as Ready to invoice.

Next, let’s look at the three different options for changing the “bill to” customer in more detail.

Option 1 – Reversing Unbilled Sales and Cost Actuals

As the original invoice has been corrected, an Unbilled Sales Actual for the original time entry transaction now exists in Dataverse. The first option is to reverse both Unbilled Sales and Cost Actuals. The downside of this is that the Unbilled Sales Actual can be invoiced again by setting it as Ready to invoice. This option is prone to user errors as it’s possible to accidentally reinvoice Unbilled Sales Actuals. This is the most straightforward option for reversing the original transactions and changing the “bill to” customer, though. Let’s go through the steps for this option.

Correcting Unbilled Sales and Cost Actuals

The existing Unbilled Sales and Cost Actuals are corrected using Journals. Take extra care when using them as incorrect entries will wreak havoc on Actuals and the consistency of financial data. As Journals are a means of creating Actuals manually, it’s very important to keep transaction origins in mind and document the created records. When using Journals to create Actuals, ProjOps doesn’t automatically track transaction origins. This means that new Actuals aren’t automatically tied to an existing time entry, approval, or invoice. Document what you’re doing and why you’re doing it when creating Actuals with Journals. For example, reference an invoice number a correction is related to.

When creating Journal Lines, make sure that data in different fields matches the data on the original Unbilled Sales and Cost Actuals. You might need to edit views or to use advanced find or browser extensions like Level up to view all relevant data. When Journal Lines are added to a Journal and the Journal is confirmed, Actuals are created in Dataverse.

When corrected Actuals are created in Dataverse, a new Project Operations integration journal is created in F&O. When the integration journal is posted, the transactions are posted to the project subledger and general ledger. You can read more about the Project Operations integration journal here on Docs.

The downside of this option is that the Time and Material Billing Backlog now has two Unbilled Sales Actuals: One for the original transaction and one for the corrected transaction. As canceling Unbilled Sales Actuals is no longer supported, especially the original transaction is at risk of being pulled on a new invoice by human error.

Changing the Project Contract Line Customer

As the original transaction has now been corrected and reversed, a new transaction for the correct “bill to” customer is needed. Since Project Operations supports multiple Project Contract Customers and Project Contract Line Customers, we’re going to leverage this feature and set a new “bill to” customer. For more information on split billing, read my previous blog post about the feature here.

A new Project Contract Line Customer is set on the Order’s T&M Order Line. Split billing percent is set to 0 for the original customer (A Lorem Ipsum Inc) and to 100 for the new “bill to” customer (The Dynamics Company Inc). The original customer will remain the order level customer, however all future transactions against the T&M Order Line will have the new customer as the “bill to” customer.

Creating new Unbilled Sales and Cost Actuals

As the new “bill to” customer has been set, new Unbilled Sales and Cost Actuals can be created. New Actuals are created by creating a Journal with Journal Lines and by then confirming the Journal. Remember to pay close attention to values in different fields and to document the process so that the origin of the transaction can be traced. As I’m writing this blog post, the Customer lookup on the Journal Line quick create has to be put on the quick create form and populated with the new “bill to” customer, for the Journal Line to point to the correct record in the Account table in Dataverse.

When the Journal is confirmed, Unbilled Sales and Cost Actuals are created for the new “bill to” customer. The Unbilled Sales Actual can now be invoiced normally by setting it as Ready to invoice and then creating an invoice and confirming it. The new proforma invoice has now been processed for the new “bill to” customer.

When the resulting Project Operation integration journal has been posted, a new Project invoice proposal can be posted. This creates a Project invoice for the new “bill to” customer in F&O.

Option 2 – Reinvoicing as Non-Chargerable

Let’s look at a new set of records. The starting point is after the invoice correction process has been completed. This means Dataverse has Unbilled Sales Actuals as a result of the correction process and those Actuals can be reinvoiced, as previously mentioned. As the correction, Journal creation, and F&O related processes have been covered in option 1, this chapter won’t have step-by-step guidance and screenshots in the same detail.

Reinvoicing Unbilled Sales Actuals as Non-Chargeable

Unbilled Sales Actuals are set as Ready to invoice and an invoice is created in Dataverse. The next step is to change the Billing Type of Invoice Line Details on the new invoice to Non-Chargeable. In this example there’s only one time entry so there’s only one Invoice Line Detail to edit.

When an Invoice Line Detail’s Billing Type is set to Non-Chargeable, the Amount of the Project-based line changes to 0, and the Total Amount of the invoice is set to 0 as well. Remember that in this example there’s only a single transaction that’s edited.

Correct and create Actuals

When a proforma invoice with Non-Chargerable Invoice Line Details is confirmed in Dataverse, the invoicing process in Project Operations is complete. Non-Chargeable transactions work differently than Chargeable and Complimentary transactions. Non-Chargeable Billed Sales Actuals are not sent to F&O as Non-Charegable transactions are not invoiced in Finance & Operations. Dataverse works differently and on that side, all transactions are invoiced. Confirming an invoice with Non-Chargeable Invoice Line Details in Dataverse means that there is no Project Operations integration journal to post and that a Project invoice proposal isn’t created in F&O. As I’m writing this blog post, there is however a bug in the process and a 0 valued Project invoice proposal without transactions appears in F&O. I will update this post when the issue is resolved.

The next step is to correct and reverse the Billed Sales and Cost Actuals that are in Dataverse. The Actuals hold a value for the incorrect “bill to” customer in the Customer ID field so they are reversed. Remember to pay close attention to all field values and document what you’re doing so that transaction origins are traceable. The Billing Type on the Billed Sales Actual is Non-Chargeable, the Cost Actual’s Billing Type is Chargeable.

When the Journal is posted, all Actuals are now reversed and corrected. As the Cost Actual’s Billing Type is Chargeable, a new integration journal is created in F&O. Posting the integration journal completes the steps required to reverse and correct transactions for the incorrect “bill to” customer.

The steps for addressing an invoice to a new “bill to” customer are exactly the same as what was covered in the chapter for option 1. As a short recap, the steps are:

• Create a new Project Contract Line Customer.
• Set split billing for the incorrect customer to 0 and to 100 for the new “bill to” customer.
• Create a new Journal with Unbilled Sales and Cost Journal Lines. Billing Type for both is now naturally Chargeable. Confirm the Journal to create Actuals.
• Set the new Unbilled Sales Actual as Ready to invoice.
• Create a new proforma invoice and confirm it.
• Post the created Project Operations integration journal in F&O.
• Post the created Project invoice proposal in F&O.

This completes the process of addressing a new invoice to a new “bill to” customer in option 2. The result is a posted invoice in F&O for the new customer.

Option 3 – Reinvoicing as Complimentary

The third option for changing the “bill to” customer is the most labor-intensive of all options. The starting point for the example is again a completed invoice correction process. This option highlights the differences in the behavior between Non-Chargeable and Complimentary Billing Types. While there has been little to no difference with regards to which Billing Type to use in previous versions i.e. in Project Service Automation, Project Operations requires a more careful consideration of which Billing Type to use when transactions are not charged from a customer.

Reinvoicing Unbilled Sales Actuals as Complimentary

Let’s assume that an original invoice has been corrected and a new proforma invoice has been created. The Unbilled Sales Actual that is created from a corrected invoice is on the new proforma invoice. In this option, the Billing Type on Invoice Line Details is set to Complimentary. The process of setting the Billing Type is the same as in the chapter covering option 2. When Invoice Line Details are set to Complimentary, the amount of the invoice is set to 0. So far the behavior is similar to Non-Chargeable Invoice Line Details, covered in option 2.

When the invoice is confirmed, the behavior of an invoice with Complimentary Invoice Line Details follows the behavior of an invoice with Chargeable Invoice Line Details. When we look at Project invoice proposals in F&O, a new invoice with a transaction is created. This means that a simple reversal of Actuals won’t be enough and the invoice should be corrected as accounting behavior is the same as with Chargeable transactions.

A second invoice correction round

As Complimentary transactions become transactions on a Project invoice proposal, we’re now in a revolving invoice correction cycle. In this option, an invoice now needs to be corrected in Dataverse for the second time. Suffice to say this third option for setting a new “bill to” customer makes no sense in an actual business scenario unless there’s some specific need to flag transactions as Complimentary. Let’s play this option through though.

When the new invoice is corrected and confirmed in Dataverse, a new Project Operations integration journal is created. The pattern is the same as when correcting a Chargeable invoice, as mentioned in chapter Dataverse and F&O after correcting an invoice. After the integration journal is posted, a Project invoice proposal will get a transaction with a negative quantity and 0 as its amount.

This lengthy correction cycle puts us back to square one with an Unbilled Sales Actual that has a Billing Type of Complimentary. The next step would be to proceed with option 1 or option 2 to change the “bill to” customer. It’s clear that option 3 isn’t worth considering. It’s not really an option at all.

Summary

The example scenario was to change the “bill to” customer after an invoice had been confirmed in Dataverse and posted in F&O. The blog post described three different options for changing the “bill to” customer, while the last option, option 3, proved to be unsuitable for easily achieving the requirement. The described options all require manual labor and are interim fixes, before transactions with billing activity can be recalled, canceled or corrected.

Disclaimer:
All my blog posts reflect my personal opinions and findings unless otherwise stated.