In environments where high volumes of invoices are produced, an organization periodically generates bills to send to their customers. The bills contain a consolidation of invoices, credit notes, and payments that have occurred since the previous billing. You can print a bill in summary form with one line per invoice or in full with item line details. The bill also contains a balance carried forward (opening balance from previous bill, activity current period, new closing balance to be carried forward to the next bill). Customers make payments with reference to bills, rather than to individual invoices.

Bills also have their own due date, based on the billing date and specific terms for bills. Bills do not replace normal invoicing, which still takes place as usual. Sales revenue and tax postings are posted during the invoice posting. However, billing enables you to group these invoices on a periodic basis in a formal bill document and send them to the customer. The bill document is an invitation to pay and its credit terms override those of the originating invoices. The original invoices remain open; the billing document is not a replacement AR. However, the billing document is to be paid as a single payment with a single payment reference.

The billing solution requirements exist formally in Japan and Thailand but billing is useful in any situation where regular customer statements with a balance carried forward are needed.

The billing programs enable you to send bills to selected customers and record the payments that the customers make.

In addition to the new programs, fields have been added in Customer Create and Modify (20.7.1) to enable you to assign a billing schedule and a bill collector to a customer.

To record bill payment, you can add billing fields in Design Mode to the following programs:

The AP Bank Charges solution is tailored to business practices in Japan. The AP Bank Charges functionality enables you to configure your system to calculate bank charges on supplier payments. Bank charges often apply to payment transfers that you make to your supplier to pay for goods or services. You must agree with your supplier who pays these. You can then configure the system to take these charges into account during the AP payment process. Banks keep a list of the charges that they apply to payments made. These charges are dependent on the bank that you are making the payment to, the amount of money that you are paying, the payment format, and the date of the payment. If your supplier pays for these charges, you can configure the system so that the charges are automatically deducted from the payment that you make to the supplier. The bank charge amount displays in the Bank Charge Amount field of Supplier Payment Create.

There are a number of steps to complete so that the system is configured to calculate bank charges on payments to suppliers:

You can include information on bank charges in the following reports:

In countries such as Portugal, it is a legal requirement to provide a digital signature for each invoice. This signature verifies that invoice creation sequence and invoice data are not altered after invoice creation. The signature is generated using OpenSSL. This requirement applies to supplier invoices just as it does to customer invoices.

In ERS Processor (28.10.13), when you click Process, an invoice is created and a digital signature is then also created. The data used to create the signature is taken from the current invoice, but the signature of the previous invoice is also included. The order of the invoices is determined based on the company, posting year, daybook, and voucher of the invoice. Digital signatures are only created for non-initial invoices.

In Brazil, it is a requirement to allow the same legal document numbering for a different site in the same domain. It is possible to have the same numbers because when the CNPJ code (GST tax ID) is different from one site to another, the unique CNPJ code ensures that each number can be uniquely identified.

To meet this requirement, the number range target dataset for legal documents allows you to create the same set of segments with the same format. In Number Range Maintenance (36.2.21.1), the target dataset for legal documents is lgd_nbr.xxxx, where xxxx can be any character.

You can create two different number ranges with the same segment formats and issue the same numbering. In Legal Document NRM (36.2.21.9), two or more different sites can be linked with independent number ranges and the same segment formats.

In all shipper confirmations, the legal document is not validated when the same legal document number exists in the same domain. In Shipper Unconfirm, the legal document related to the unconfirmed shipper is reverted and the status changed to Canceled.

In sales and in DRP flow, it is common in Brazil to issue separate legal documents for the material and the container because different taxes may apply to them. In addition, containers are sometimes unplanned issues and the customer is not charged for them. Therefore, you also need to be able to specify whether a container legal document has an impact on AR.

To treat the container separately from the material and to create separate legal documents and GTM usage, you must perform the necessary setup. In Container/Line Charge Control (7.22.24), select the Separate Legal Doc for Container field. This value is set at global level and also by default at customer level in Ship-To Control Maintenance. You can change the value for each customer.

To treat the container as an unplanned issue, in Container/Line Charge Control, select the Recalculate Container Taxes field. This field indicates that you are using a different GTM base for the container, and tax is determined according to the container lines on shipper. It is not accounted for in AR or displayed on the customer invoice. You can also set this field at customer level in Ship-To Control Maintenance.

In Brazil, all transactions are subject to tax, including Distribution Requirements Planning (DRP) transactions. In DO Shipper/Pre-Shipper Maint (12.19.3), you can set specific tax parameters at header, container, and line level. You can also set the container and unit price. The shipper trailer contains a Tax Totals frame that displays the total tax for the shipper.

When you then confirm the shipper, all taxes are calculated automatically, and legal documents with the relevant prices and taxes are produced. The tax postings are also created in the GL.

To enable you to specify container taxes, you must complete the relevant setup in Global Tax Management Control (29.24). On this screen, the Apply Tax On Issuing Transactions field must be selected and the Transaction type must be set to ISS-DO.

After you create a distribution order in Distribution Order Maintenance (12.17.14), use DO Shipper/Pre-Shipper Maint (12.19.3) to create a shipper. This program enables you to enter tax parameters for the container separately to the materials. A separate tax frame is displayed for the container.

When you enter the container content details, you need a base amount to calculate taxes. The Unit Price field enables you to specify the cost per unit. The default unit cost is automatically displayed in this field. When you click Next, an item level tax frame is displayed, which enables you to enter tax parameters at an item level.

When you have completed all shipper lines, you can select the View/Edit Tax Detail field to view tax details. When you confirm the shipper in DO Pre-Shipper/Shipper Confirm (12.19.13), all taxes and accounting transactions are calculated for the shipper.

If you have created a DRP shipper with an error in the fiscal data or GTM usage, you need to be able to unconfirm it. As a workaround, to unconfirm a DRP shipper, use Non-sales Shipper Unconfirm (3.15.2). This program enables you to unconfirm a legal document with the status Confirmed by sending a generated file to the government. There is no related inventory transaction.

When you have corrected any errors, use Non-Sales Shipper Confirm (3.15.1) to confirm the DRP shipper again. In this way, you avoid reissuing inventory.

To meet requirements in some European countries such as Czech Republic and Italy, you can now set up your system to disallow issuing an invoice for a single sales order with different shipment periods on an order. For multiple sales orders, you can also set up the system to prevent the user from combining orders with different shipment periods. The periods can be by month, quarter, year, or any defined calendar date period. The calendar used can be either GL or Tax calendar, depending on the configuration.

In Container/Shipper Control (7.9.24), when Separate Invoices for Each Shipment is selected and one of the options Always, By Tax Period, By GL Period is selected, you cannot confirm the current shipment when there is any pending invoice for the same sales order. By default, Separate Invoices for Each Shipment is not selected.

You can also add a check to disallow the combining of multiple sales orders with different Ship-from Tax Zone into one invoice. To add this check, in Sales Order Accounting Control (36.9.6), make sure Consolidate Invoice by Various Ship-From is not selected.

The legal document number is now available in the dataset of the following reports, so you can include it on a report when there is a country-specific legal requirement: