Setup and usage of contract accounts

[henk_hoogerbrug]

Hello,
We are reviewing our FI-CA administration and want to include more SD flows into FI-CA.
I was wondering if there are people in this community who can share their knowledge regarding the definition of contract account types and usage of contract accounts.
So for example: should we use one contract account type and create multiple contract accounts, or is it a best practice to define several contract account types.

We already have 2 divisions (electricity and gas) in use to support our IS-U processes. I expect some additional divisions to be created, because not all our products/services will fit into one of those divisions.

Best Regards,
Henk Hoogerbrug

[SaschaWenzel]

Hi Henk.

I would go for different types (e.g. Utilities and a new one for Sales) having different number ranges. Makes life easier, when you run mass activities and do the selection via contract account numbers.

BR,
Sascha

[henk_hoogerbrug]

Hello Sascha,

Thanks for your reply.
Makes sense to split it this way, also because we don't want to interfere with all IS-U related improvements and changes.

Best Regards,
Henk Hoogerbrug

[william_eastman]

Hi Henk:

Of course the system can accommodate many designs here.  It depends on how you want to process the receivables for these SD charges and who processes them.  In NA, most utilities want a single invoice inclusive of all charges both commodity and non-commodity, so a single contract account used for both processes is the norm.  If you need/want to keep them separate, then a distinct CA type makes sense and can enable you to filter the account selection in SD either manually or in an automated fashion.  As a general rule, more master data makes it more challenging for users so i would always look to minimize that while still enabling the processes as necessary.

regards,

bill.

[henk_hoogerbrug]

Hello Bill,

We have several SD flows we want to integrate in FI-CA. Some flows must be treated separately, e.g. we may not clear credit notes from that flow with debit notes from another flow, because there is an agreement to pay the customer.

The biggest part of the SD customers are not related to IS-U, so the single invoice is not a very hot topic.

I agree the we need to keep the master data as less as possible.

Best Regards,
Henk Hoogerbrug

[PieterB · Accepted solution]

Hello Henk,

we have done this set-up with different contract account types in order to invoice smart thermostats, maintenance plans and subscriptions. The main reason for this was to split the dunning and collection part of this from the commodity (E & G) part. Of course it is more master data to handle, you will not be able to meet a future requirement of 1 invoice and you need to build in some checks to avoid that these contract account types are used for Utilities contracts and that Utilities contract account types are used for SD orders / contracts. Building in this checks is quite straight-forward. 

Depending on our use cases it could also be interesting to investigate the usage of convergent invoicing with/without an integration with SAP IS-U. 

In case of any follow-up questions, don´t hesitate to reach out to me.

Cheers,

Pieter

[henk_hoogerbrug]

Hello Pieter,

Thanks a lot for your additional information. This will also help us in making decisions.

We are aware of convergent invoicing and maybe it will have added value for us in the future, for now our focus is to create a solid basis.

Best Regards,
Henk Hoogerbrug

[PieterB]

Hello Henk,

You are welcome. Good luck with your decisions and the solid base!

Regarding CI: here a link to an interesting blog post of my colleague Oleh: SAP Billing and Revenue Innovation Management: com... - SAP Community

Cheers,

Pieter