This is one topic which cannot be summed up in a single post. So this post is kind of abstract post which would talk about the general terminology. Subsequent post shall take up each topic and possibly showcase a demo. Nothing more can supplement thehelp.sapsite. The below text is just a summation of whatever you read in thelink.A utility company usually bills its services at the end of a supply period. This can be periodic billing or even annual billing. With the high utility bills customer can generate even paying the periodic bills takes time for the customers, causing the execution run of dunning and installment plans. But the utility firm needs cash to maintain its current business so it can switch to Budget Billing amounts instead of the amount the customer is expected to owe, so that the utilitys liquidity is maintained.The basis of Budget Billing is the Budget Billing plan which sets the due dates and the Budget Billing amounts. The system can automatically create Budget Billing plans during invoicing or move-in processing. However, one can create them manually too. Contracts that have to be invoiced together (joint invoicing) are assigned a common Budget Billing plan. All other contracts in the contract account can have their own separate Budget Billing plan. Budget billing amounts can be stored either as down payments (statistical receivables) or as partial bills (debit entries) inContract Accounts Receivable and Payableand are therefore subject to all dunning and payment procedures.There are 4 Budget Billing Procedures as mentioned and explained below.1. Statistical Procedure2. Debit Entry Procedure (Partial Bills)3. Payment Plan Procedure4. Payment Scheme ProcedureFirst a bit on the categories of Budget Billing. IS-U/CCS supports Average Monthly Billing (AMB) and Budget Billing Procedure (BBP) as special budget billing categories applicable to North America.InBudget Billing, an average amount is determined either through simulation or manually. The customer pays that average amount for a period of 12 months. At the same time, the customers actual consumption is billed, and the results are printed on the bill. In addition, the difference between the customers actual consumption and the average amount is calculated, updated monthly, and printed on the bill. In the last month of the meter reading period, the actual amount and the accumulated difference are billed.InAverage Monthly Billing, the customer is charged an average amount based on billings over the lastxmonths (we can define the number of months, including minimum and maximum number of months, in Customizing). In addition, the customers actual consumption is billed, and the results are printed on the bill. The amounts due for later months are calculated using the average of the previous monthly bills, the current bill and the accumulated difference. That difference is updated monthly and is printed on the bill.Parameter Records have a special role to play as they along with the portion which decides on the BB cycle and the due dates. The due dates for the budget billing amounts are calculated directly from theportionapplicable to the contract and from theparameter record.The following data is defined: The length of the budget billing period (a number of months or a year) The budget billing cycle, meaning the equal distribution of dates over the period (one or more months)However, one can override the preset values from the portion either in the budget billing plan itself or in a contract. While changes made in the budget billing plan take effect immediately, entries made in the contract do not take effect until the budget billing plan is created again.Every parameter record can contain up to 5 budget billing cycles. One can select the following values: 00: No budget billing amounts are levied 01: Budget billing amounts are levied every month 02: Budget billing amounts are levied every 2 months 03: Budget billing amounts are levied every 3 months 04: Budget billing amounts are levied every 4 months 06: Budget billing amounts are levied every 6 months 12: Annual payer; one budget billing amount is levied.When we define a budget billing cycle, we must enter the budget billing cycle as well as the scheduled print date of the budget billing request or the creation of the partial bill in theBB req./part. billfield.In the fieldMonthsinv.-1stBB, we define the time between the end of the last billing period and point when the first budget billing amount is levied.If we want to use the parameter record to create portions with a duration of days, we need to enter the number of days after the start of this period that we want the first budget billing item to be calculated in the fieldDays to Bud. Bill. The system uses this number of days to calculate the other budget billing items.

Parameter RecordIn the portion we have the following fieldsBB/Bill Dates (Group Due Date of Budget Billing Items and Bill)Here, you can define whether you want to group the due date together with the next budget billing amount or with the next bill.Dun Due Date (Dun the Last Due Date of a Budget Billing Plan)This indicator is only used for the statistical budget billing plan procedure. When it is set, the Cannot Be Dunned in BB Plan field is not set.Define Budget Billing CyclesWhen we select the budget billing cycle, we can specify the number of budget billing amounts that are charged. If we want to levy budget billing amounts, at least one permitted budget billing cycle must be set with the number of budget billing amounts.Budget Billing CycleWe can define a cycle in the portion as a standard cycle. We can only use budget billing cycles that are defined in the allocated parameter record. If we do not levy budget billing amounts, no data is saved in the budget billing data table TE423 (Budget Billing Dates) when the schedule records of the portion are generated.If we define more than one cycle, the entries for every cycle are saved in the table TE423.

PortionBudget Billing Amount CalculationThe system calculates the budget billing amount on the basis of the expected meter reading results (Extrapolation). Extrapolation can be based on the following information: Amounts from the last bill. The extrapolation lines for the budget billing amounts are generated automatically during periodic billing. Periodic consumption Reference value in the rate Manual specification of the budget billing amountsThe following functions are also available for calculating the budget billing amount: In the case of an interim billing, one can specify whether the remaining budget billing amounts are to be adjusted. In the case of budget billing, one can also perform mass changes.1. In case ofstatistical budget billing procedure, the budget billing amounts are displayed as a statistical posting (not a posting in general ledger) in the account balance display.0. In case ofpartial bill procedure, the individual amounts are entered as a receivable on the debit side after the completed partial bill run. The budget billing amounts are not displayed in the account balance display immediately after the budget billing plan has been created unlike statistical budget billing. The budget billing plan is managed for the partial bill procedure in a shadow table (DFKKMOP and DFKKMOPW). This is not used by FI-CA. After the report Create Partial Bill (transaction EA11) has been started, the item is posted in FI-CA (debit entry). This is an actual posting with VAT.0. In thepayment plan, the utility company and the customer decide on the amount to be paid with each bill. So instead of paying the actual bill amount, which varies according to season, the customer pays the payment plan amount. The utility company records the difference between the payment plan amount and the actual bill amount and charges it at a later date. Depending on the category to which the payment plan belongs, or depending on the settings in the contract, the difference amount is reimbursed or charged to the customer when the payment plan expires or, at the very latest, when the customers moves out of the premise. Consumption billing must take place for every due date of the payment plan. Because of this,the payment plan is not comparable to a statistical budget billing plan or a partial bill, in which the relevant amounts are charged in between two periodic bills.Also we can only create payment plans from category BBP. Payment plans from category AMB are not actually created but are managed as virtual payment plans in the system based on the start month or alternative start month defined in the contract. When the monthly bill is created, the payment plan data is evaluated and included in the calculation of the payment plan amount.

Payment Plan0. Thepayment schemeis a statistical budget billing procedure. In this procedure, the system determines the budget billing amounts to be paid based on the consumption billing amounts of past and current billing periods, and distributes these evenly across the next billing period. The system calculates the budget billing amount from an extrapolated portion, which reflects the expected consumption for the current billing period, and a known portion from the copied consumption billing. Point to note is that we can only use the payment scheme procedure with the Customizing setting Tax Determination in Billing. We cannot use the payment scheme procedure in combination with multi-level tax determination (for example, Tax Jurisdication Code). The amount of a payment scheme item can never be smaller than zero. Therefore, a payment scheme cannot have a credit subtransaction.I think this is enough context for subsequent posts on Budget Billing. Coming up would be posts on each of the Budget Billing procedures. I would be updating the links on each post as they come up. Also I have missed marking out the enhancements/Function modules here so would be updating them in the individual posts as they come up.Thats it. Enjoy.

So second in the series isPayment Scheme. As always most of the content here is copied from help.sap. (link ishere). So instead of rewriting whats already written, I would try to present it in the system (maybe).A little summation on Payment Schemes.1. The payment scheme is a statistical budget billing procedure i.e. The amount to be paid is based on theconsumption billing amounts of past and current billing periodswhich is prorated across the next billing period.2. Payment scheme allows payments in intervals/frequency like Weekly, Monthly, Quarterly etc. Here the screenshot shows the Frequency as Monthly.

Open Items for Selected Contract3. Payment Scheme period is not limited. When a periodic bill is created, the system does not end the payment scheme but adjusts it. Therefore, if a periodic bill is late, we can at least charge the customer for the previous budget billing amount.4. In addition to consumption billing, we can include/exclude all other credit and receivables items from the same contract in the payment scheme.5. Payment Scheme cannot be used along with Collective Bills.6. Payment Scheme has to be createdmanually either during the move-in process or via the transaction EA61PS. BOR Object isPAYSCHEME.

Payment Scheme Creation7. In Contract Account the Budget Billing Procedure is defined as4 Payment Scheme.

Budget Billing Procedure in Contract Account8. As with Payment Plan, Payment Schemes can be assigned to one sub transaction.9. Payment Scheme cannot be used in conjunction with Tax Jurisdiction Code as it doesnt work with multi-level tax determination.10. The value of a payment scheme item can never be lower than zero.11. Wecannot create a payment scheme with a start date that lies in the past.12. When a payment scheme is created, a sample line (in tableEABPL) is created for each contract in addition to the header data (in tableEABP). This line contains all data relevant to the payment scheme such as amount, payment frequency, first payment date, and so on. This request data is also determined from the payment scheme sample lines. They represent the most important connection betweentheSAPUtilities data and the contract accounts receivable and payable data in this procedure.

Table EABPL and EABP13. The system determines the extrapolation period in eventDefine Extrapolation Period for the Payment Scheme(R510). In the standard logic provided bySAP, the system sets the start date of the extrapolation period to the start date of the current periodic billing period. If the move-in date is within the current billing period, the system chooses this date. The end date is the same as the end date of the current billing period. The system uses this data to carry out extrapolation for the contract.14. The system first determines the payment scheme amount for each due date item. The extrapolation amount determined in event R511 and the amount from the open items that was transferred to the payment scheme are added together.This sum is divided by the number of payment scheme requests remaining in the billing period. The number of payment scheme requests depends on the start date of the payment scheme, the payment frequency, and the end of date of the billing period.15. The Payment scheme would be having one of the below status at any point of time in the system.

Payment Scheme Status16. Deactivation reason for Payment Scheme can be due to the below reasons.

Deactivation Reason in Payment SchemePayment Scheme adjustment can happen cause of Periodic Billing and Interim Billing.

Change Status of Payment SchemeHere I am talking about Periodic Billing. For more details on this do look at thelink.So adjusting a Payment Scheme during Creation of a Periodic Bill0. During creation of the Periodic Billing document, the system carries out an extrapolation for the subsequent periodic billing period. This can result in an adjustment to the payment scheme amount.1. As part of this adjustment, one can add the receivables and the credit items from the current consumption billing, as well as other open items that are part of the current consumption billing, to the payment scheme.2. With a periodic bill, any unpaid payment scheme requests that have a due date within the billing period become invalid. If these requests have already been included in a dunning run, the information isno longeravailable once the periodic bill has been created. If we execute the periodic invoicingbeforethe scheduled date, all existing future payment scheme requests that are due up until the planned periodic invoicing date are reversedwithouta follow-on posting.3. If the customer has already paid budget billing requests with due dates after the end of the billing period, these payments are taken into account when the extrapolation portion of the payment scheme amount is adjusted. This means that the newly determined extrapolation amount is reduced by the value of the requests that have already been paid. The remaining amount is divided amongst the remaining payment scheme due dates.4. The system marks open items for transfer to the payment scheme and transfers them to eventTransfer of Open Items during Invoicing(R415). We can also use this event to exclude certain items from being transferred.HOW THE EXTRAPOLATION WORKSA periodic bill is created for a customer on January 1. The payment scheme to be adjusted has a monthly payment frequency and with the payment date on the 25thof each month.Say the extrapolation for the period January 1 to December 31 results in a gross amount of EUR 1200.The following items are transferred to the payment scheme: Additional payment of current periodic bill: EUR 120 Account maintenance: EUR 40 Request with Invoicing: EUR 80The full amount transferred to the payment scheme is EUR 240.Number of open payment scheme requests until the end of the new periodic bill: 12 (from the extrapolation period of 12 months)After the payment scheme has been adjusted, the new amount is (1200 + 240) / 12 = EUR 120From EUR 120, this consists of an extrapolation amount of EUR 100 and open items transferred to the payment scheme to the value of EUR 20.0. Once a payment scheme has been adjusted, the system carries out an amount and percentage limit check of the changed payment scheme sample lines before the changes are written to the database. This setting is done in customizing (Table is TE558)1. The checks take place atcontract levelregardless of whether the contract is optional or mandatory. The system carries out the check in event Check Amount/Percentage Limits for Automatic Payment Scheme Adjustment(R514), for which SAP provides a standard logic.2. For terminating a Payment Scheme, enter the End date and the Deactivation reason. Once the end date has been given, the system checks whether payment scheme requests that have already been paid exist after the end date. If this is the case, the end date is set to the next due date plus one day. Depending on the sequence of the end date and the first payment date of the payment scheme, the system proceeds as follows:> If the end date isbeforethe first payment date of the payment scheme, the payment scheme is deleted from the database. If statistical requests for this payment scheme are already created, they are cleared.> If the end date isafterthe first payment date of the payment scheme, the system executes the following actions: The payment scheme sample line that is active on the end date is prorated so that its end date is the same as the end date of the payment scheme. A new sample line is created for the part of the sample line that comes after the end date. All payment scheme sample lines with a start date that comes after the end date are deactivated. The end date and, if necessary, the deactivation reason are entered in the payment scheme header data. All statistical requests with due dates that lie after the end date are cleared.0. In order to ensure that a payment scheme can no longer be changed, one mustdeactivateit once it has ended.1. Requests with due dates that come after the most recent interim or periodic bill and that have already been paid are settled against the current consumption billing when the bill is created.2. If the interim/periodic bill is reversed, the entire process is cancelled. This means that the clearing of the paid requests against the transferred items and the current consumption billing is also reversed.3. We cannot delete a payment scheme from the system, it can be archived though.4. Migration Object for Payment Scheme is BBP_PAYSC5. An important customizing has to be maintained for SAP UtilitiesunderInvoicingBasic SettingsDefine Basic Settings for Invoicing, chooseTax Determination in Billingfor the time of tax determination.The following events are available for the budget billing procedurePayment Scheme.

List of Events in Payment Scheme Determining the Extrapolation Period for the Payment Scheme(R510) Determine Payment Scheme Lines from Billing Document(R511) Determine Budget Billing Amount for Payment Schemes(R512) Adjust Payment Scheme for Periodic/Interim Bill(R513) Check Amount/Percentage Limits for Payment Scheme Adjustment(R514) Selection of Open Items when Creating a Payment Scheme(R515) End Payment Scheme(R516) Activate Payment Scheme(R517) Customer-Specific Checks for First Payment Date(R518) Customer-Specific Checks for Start Date and Change Date(R519) Customer-Specific Checks for Creation Status(R520) Checks for Retaining Payment Periods(R521) Define Printing Rules for Change/Creation Documents(R522) Notify Activation of Payment Scheme(R523) Print Change/Creation Documents(R524) Adjust Customer-Specific Fields for Payment Scheme(R525) Amount Limit Warning Ignored(R526) Customer-Specific Rules for Amount Rounding in the Payment Scheme(R527) Override Selection of Open Items(R528) Change Meter Reading Unit During Creation/Change of Payment Scheme(R529) Execute Amount Checks(R530) Automatic Account Maintenance when Payment Scheme is Ended(R531) Determine Deactivation Reason for Payment Scheme(R532) Divide Bill End Amount(R533) Adjust Customer-Specific Tables(R534) Determine Minimum Number of Days Between Creation Date and Due Date(R535). Adjust New Lines(R536) Suppress Interval Adjustment During Generation of New Lines(R537) Display and Change Customer-Specific Fields(R538) Enhancing Display Structures(R539) Determine Billing Transaction and Document Types of Included Items(R540) Select Contract Accounting Items for Payment Scheme(R415) Incl. Items w. Different Tax Codes(R543) Determination of Tax Code for Requests(R544) Reactivation of Payment Scheme on Move-Out Reversal (R572)Below are some screenshots of how the Payment Scheme works in the system. For now this Contract doesnt have any previous billing history maintained in the system. So on the date of move-in the Payment Scheme has been activated. For the current Billing Period extrapolation is done and an Estimated amount of EUR 1 is written down as shown.

Payment Scheme Created for Selected ContractThe Estimated Billing Document as a result of extrapolation during the creation of Payment Scheme is shown below.

Estimated Billing Document for Payment SchemeBelow are the screenshots of the Billing line items which show the actual consumption amount for the current period and the prorated consumption amount for the next billing period which has the Budget Billing Item checked.

Actual Consumption Billing documents with Payment SchemeThe same is reflected in the Payment Scheme as shown below.

Display Payment SchemePayment Scheme would require the End Date and the Deactivation reason as shown below.

Terminate Payment SchemeFor now this Contract has previous billing history maintained in the system. So when the Payment Scheme is activated it asks for importing the open items from the contracts.

Open Items for Selected ContractsOnce Payment Scheme is created the amount is extrapolated for the current period as well as for the future period.

Payment Scheme for Contract having consumption historyThe Estimated Billing document created by the Payment Scheme is shown below and the subsequent actual consumption Billing Document too.

Estimated billing Document

Actual Consumption Billing DocumentThere are many scenarios which I have not talked about as they would require more time to explain, ( but anyways probably later some day) , these can be found out in theSAP linkwhere they are described in detail.

So first in the series is Payment Plan. As always most of the content here is copied from help.sap. (link ishere). So instead of rewriting whats already written, I would try to present it in the system.A little summation on Payment Plans.1. In the payment plan, the utility company and the customer decide the amount to be paid with each bill.2. Depending on the settings that have been defined in Customizing, one can either enter an amount for a predefined period (generally 12 months) in the payment plan, or can use the previous bills to calculate an average value for the current bill. The first payment plan can only be valid for a period of less than 12 months.3. The budget billing amount is determined in event R950. SAP provides the following standard function with function module ISU_CALC_PAYPLAN_AMOUNT. More on this can be readin the documentation of the event.4. Depending on the category to which the payment plan belongs, or depending on the settings in the contract, the difference amount is reimbursed or charged to the customer when the payment plan expires or, at the very latest, when the customers moves out of the premise.5. Consumption billing must take place for every due date of the payment plan. Because of this, the payment plan is not comparable to a statistical budget billing plan or a partial bill, in which the relevant amounts are charged in between two periodic bills.6. The allocation of a business partner to a payment plan takes place at contract level.7. Select budget billing procedure 3 in the relevant contract account.

BB Procedure in Contract Account8. One can only create payment plans from category BBP. Payment plans from category AMB are not actually created but are managed as virtual payment plans in the system based on the start month or alternative start month defined in the contract. When the monthly bill is created, the payment plan data is evaluated and included in the calculation of the payment plan amount.9. A payment plan item can only ever be assigned to one sub transaction.10. The amount of a payment plan item can never be lower than zero. Therefore, a payment plan item cannot be assigned to a credit sub transaction.11. One can only create a payment plan for one monthly budget billing and billing cycle.12. The system uses the billing allocation date from the schedule record of the portion as the due date for the individual payment plan items. Since this date does not define the date by which the customer has to pay the amount, the system displays the bill month.13. If its defined in Customizing that no amount is charged in the last month of the payment plan period, the system creates the item with the amount zero. Its un-editable.14. If joint display of payment plans is requested then in the contract that the payment plan belongs to, the Joint Invoicing indicator must be set to value 1 Contract must be invoiced with other contracts and also the payment plans that you want to display together must have the same start date.15. If we delete the start month from a contract, an existing payment plan for that contract is ended when the nextinvoicing run takes place.

Payment Plan in Contract16. If the invoicing document, in which the payment plan was ended, is reversed, the end date of the payment plan period is restored to its previous value.17. The budget billing-relevant data does not have to be maintained in the parameter record.18. In order to create a payment plan for a contract, the meter reading unit that belongs to the contract must be allocated to a portion with a monthly billing period. The payment plan procedure does not work with other billing periods.19. Since the payment plan procedure only supports a monthly billing cycle, the Permitted Budget Billing Date and Budget Billing Cycle fields in the portion are obsolete and therefore do not need to be maintained.20. The fields Combine Due Date of Budget Billing Item and Bill, Type of Extrapolation for Waste Disposal, and Dun Last Due Date fields are not relevant for the payment plan procedure and therefore do not need to be maintained.21. For a payment plan, the due dates of the individual payment plan items correspond to the allocation dates of the monthly billings that occur in the payment plan period. The due date in the payment plan item is only used to allocate the individual items to their corresponding monthly bills.22. The following payment plan categories exist (already discussed in a previous post): Budget billing plan (BBP): As we can see below the Budget Billing Amount is calculated by the system for the starting payment plan as $105. If this is a new customer then we need to maintain manual history to define the pattern of consumption. As shown in the below under Manual History (its down below in this post) the net amount is $1260 which comes to $105 per month.

Initial Payment PlanBudget bill amount can be changed for periods which have not been billed.

Change amount in Payment PlanNow I have executed Invoicing and as we can see in the line items, we habe the actual consumption amount as $100, the payment plan amount as $105 and the difference amount as $5. These have different line item types as shown.

Payment plan : BBP line itemsIn the payment plan display we get the below display after the first invoicing run. The status becomes green and also we can see the Current difference amount as $5.

First Payment in Initial Payment PlanNow here we have invoiced for the whole year,as we see all the status has changed to green, and the Current difference amount is also put back as $0 and put into the invoice.

Second Payment PlanHere is the last month invoice when the payment plan culminates, and a new payment plan starts.

New Payment Plan : BBPAs we see here the new payment plan start and end dates. Once the 2012 payment plan ends the new one gets created automatically for 2013 when the invoice for December is executed.

Payment plan createdNow if we check the new payment plan we see a new amount calculated (from the past 12 months consumption history) and the current difference amount set as $0.

New Payment Plan createdNow as has been mentioned in point 17,to end a payment plan we just need to remove the start month from Contract. Here that was done and we see that the payment plan has a different end period and the invoice line items just show the consumption amount.

Ending Payment Plan : BBP23. Average monthly billing (AMB): In this case we cannot create a payment plan but can use the transaction to check what the amount is been charged as budget bill (screenshot below). The changes needed in contract are shown below which is just the change in payment plan type.

Payment Plan :AMB in ContractThe payment plan mentioned in the contract gets first priority when creating payment plan, if there is different one used for creation it asks for confirmation. Now $105 is the amount to be charged in AMB as shown and calculated by the system.

First month payment : AMB

Second Month Payment :AMBFor the next month the amount calculated is $145.The FM ISU_PAYPLAN_SIMULATE determines the payment plan amount. First the simulation period is calculated which is defined as the old bill end period and the number of active bill days.In this case its (last day of the first period) 01312012 + 30 days = 31 daysISU_CALC_PAYPLAN_AMOUNT is called. The actual consumption for the first month is $150.Minimum days is calculated as 1*30 and maximum days is calculated as 12*30If simulated days calculated is less than minimum days (30) then error message of check if enough history is available is given. Here its sufficient. After this the amount is calculated as actual total amount * min days / simulation days. Its 150*30/31 which comes to 145.16 after rounding becomes 145.If data for Payment Plan is already maintained in Contract then that precedes the data given for creating a payment plan.24. We use the Adjust Payment Plans Automatically transaction (transaction code EK93M) to adjust active payment plans that belong to category BBP. We can make a percentage increase or decrease to payment plan item amounts. However, any items that have already been requested in a monthly bill, or items whose due date lies after a move-out date are not adjusted. Event R954 to prevent the adjustment of individual payment plans can be used.

Adjust Balance Forward Amount

How it works25. Display Payment Plan: Status of Payment Plan ItemsStatus (traffic light)Meaning

GreenPayment plan items that have already been included in an invoicing run.

YellowPayment plan items with a due date that lies in thefuture.

RedPayment plan items with a due date that lies in thepast.

Stop signAll items with a due date that liesafterthe move-out date (for contracts with a move-out date).

Status of Payment Plan Items26. Manual HistoryWe use the Manual History transaction (transaction code EK95) to create the manual history.When calculating payment plan amounts in the standard version of event R950, the system only interprets the amount history. If we create a consumption history, it is necessary to define own functionality for event R950 and, if necessary, event R955.

Maintain Manual History

Manual History27. The Balance Forward AmountA utility customer participating in a payment plan procedure does not pay the actual amount stated in the monthly bill but pays a payment plan amount. This either remains constant for a one year period (payment plan category BBP), or it varies from month to month (payment plan category AMB). The difference between the payment plan amount and the actual bill amount is written to a balance forward amount.Payment Plan Amount and Balance Forward AmountThe separation of the payment plan amount and balance forward amount to be requested occurs at document line item level. At this level, the bill line items from the billing document have been created but not yet posted.To ensure that the balance forward lines are not prematurely dunned or cleared by a payment, they are assigned a special clearing restriction (3), a dunning lock, and the due date 31.12.9999.28. Adjusting the Balance Forward Amount ManuallyThe balance forward amount consists of the accumulated difference between the actual billed amount and the amount defined in the payment plan. This difference can be positive or negative and can be any value. Therefore, it may necessary to adjust it under certain circumstances. .In the Adjust Balance Forward Amount transaction, we can select a contract and enter a new balance forward amount. We can also enter posting parameters such as posting date, document type, and reconciliation key. Depending on whether the new balance forward amount is higher or lower than the current amount, either the credit items or the receivable items are allocated clearing restriction 3.

Adjust Balance Forward AmountA document gets posted which is the sum total of the current differential amount ($15) and the new difference amount that we would mention.29. IS Migration Workbench Migration object BBP_EXT.30. EventsEvent R940/End Payment Plan? (ISU_SAMPLE_R940)Event R951: Check Payment Plan Amount for Current Bill, if Nec. Change or End Pymt Plan (ISU_SAMPLE_R951)Event R953: Determine Whether the Payment Plan Amount is Checked (ISU_SAMPLE_R953)Event R955: Verify Whether the Payment Plan Amount is to be adjustedDone .:)