Billing Accounts and Statements

If the order frequency is above 5 or 10 transactions per buyer per month, we would recommend Billing Accounts for your buyers.

Billing Accounts govern the generation of statements of account. Statements of account list all the Captures and Refunds from a given period.

Hokodo encourages buyers to pay Statements rather than the individual invoices. That way, buyers need only to reconcile one bank statement line with one Hokodo Statement. The alternative would be to reconcile many bank line items with many invoices. We provide tools so that buyers can reconcile the Statement contents against their systems.

Large volume Buyers are more at risk of reaching their Hokodo Credit Limit. Billing Accounts determine the due date of payments for orders, such that terms don't need to be selected by the buyer on an order-by-order basis. For instance, if a Buyer is often reaching their credit limit whilst on a Billing Account with a monthly period, move the Buyer onto fortnightly terms in order to keep them within their credit limit.

It is possible to provide an email address in the Billing Account to whom the Statements will be sent. This is useful if the person who makes payments and should receive the Statements is a different user to the user placing orders.

Setting up a Billing Account

Once enabled for your platform by your Customer Success Manager, Billing Accounts can then be configured

• By API: see Billing Accounts,
• Or in the Merchant Dashboard if you select a particular Buyer.

Periods and Dates

Billing Accounts can be set up to create Statements on a

• Weekly,
• Fortnightly, or
• Monthly

basis. For these periods, the following dates are configurable by your Customer Success Manager:

Field	Description
Start Date	When the Statement period starts, e.g. the 5th of the month
Due Date	When the sum owed for the Statement should be paid

Payment Plans and Billing Accounts

The Billing Account Due Date determines when payment for Captured invoices will be due. Buyers with a Billing Account will only be served one Payment Plan in the checkout: that which corresponds to the terms of their Billing Account.

Further info on dates can be seen at the bottom of this page.

Organisations and Consolidated Statements

A buyer’s company may be split into multiple sites. If so, we recommend that each site is represented as an Organisation.

It may also be that within one site, there are particular groups of users that should be treated separately. In this case, you can create an Organisation for each of these groups.

The organisations field on the Billing Account can be used to set which Organisations should appear on a statement.

Multiple Organisations can be listed on the Billing Account. When this is done, the Statements will be consolidated over those Organisations. Use the organisation.name field to easily identify each site or branch of the Buyers' company.

If - on the other hand - the buyer’s preference is to receive separate Statements, then create multiple Billing Accounts and put Organisations separately on each.

Emails

The email addresses supplied in the Billing Account are the addresses to which we will send the statement email.

Implementation with Deferred Payments

When creating Orders

We associate Orders to Billing Accounts according to the Billing Account of the Organisation. In other words, if an Organisation is added to a Billing Account, then any Orders associated with that Organisation will themselves be associated with the Billing Account.

Associating Documents with Statements (optional)

The Statements are a list of the Capture and Refund Post-Sale Events that take place in sequence.

Voids

Voids are not included on the Statement as voided amounts were never Captured.

• Invoice documents are usually associated with Capture notifications and
• Credit Note documents with Refunds.

To ensure the correct invoice or credit note appears on the correct Statement, a linkage between order documents and Post-Sale Events must be created. There are two options for doing this depending on the sequencing of API calls that makes sense for your application.

Option 1: Creating Post-Sale Events first

If you usually get documents (invoices; credit notes) some time after you're aware of a delivery or refund, you should send us the Post-Sale Event first, and add the OrderDocument as soon as possible.

1. Apply the Capture or Refund
2. When uploading the OrderDocument, supply the PostSaleEvent id as event_id in the metadata in order to associate the OrderDocument with Post-Sale Events.

Option 2: Upload Order Documents first

If it makes sense in your application to upload order documents first:

1. Create the OrderDocument
2. When applying a Capture or Refund, supply the OrderDocument id as order_document_id in metadata in order to associate Post-Sale Events with OrderDocuments.

Changing the period of a Billing Account

It might be that a Buyer wants to move from monthly to weekly terms. This could be because they are consistently reaching their credit limit when on monthly terms.

It is not currently supported to have two active Billing Accounts.

To transition the terms of a Buyer:

1. Set the Billing Account active field on the old Billing Account to FALSE
2. Create a new Billing Account on the new terms

The deactivated Billing Account will still produce a Statement on the End Date, including any Post-Sale Events that were associated with it. However, new Post-Sale Events will only be assigned to the new active Billing Account.

Statements

Statement Email

The statement email consists of:

• a PDF attachment of the statement summary
• a URL to a .zip download of all the invoices and credit note documents you have respectively associated with Capture and Refund events
• a CSV file containing the rows of data in the statement, for your buyer to use for reconciliation purposes

The statement summary PDF and CSV

The summary can be configured to suit your needs. Please ask your Customer Success Manager to configure this. See below for a screenshot of a statement.

Configuration options:

• Your company logo can be added to the header
• Any metadata field supplied in Capture and Refund events can be configured by your Customer Success Manager to appear in statement PDF and CSV files. This can be used to make tax information appear on Statements, perhaps as the tax amount or the invoice amount net of tax.
• The columns can appear in any order too, and the 'standard' columns "Invoice date", "Company/Site name" (as defined in organisation.name), "Site ID", "Type", "Invoiced", "Refunded", "Paid" and "Balance" can be removed if desired.

Further info on Statement Dates

All statement dates are configurable by your Customer Success Manager, within certain constraints.

due_date

due_date can be increased to allow the buyer more time to pay.

This is configured as an "offset" of any positive integer. 0 means that payment is due on the end_date of the Statement, 30 means that payment is due 30 days after the end_date of the Statement, and so on.

start_date

start_date can be configured to any day within the billing period.

For example, if it’s conventional in your industry for the statement period to run from the 5th to the 5th of the month, we can configure start_date to be the 5th of the month.

• For monthly statements, start_date cannot be after the 28th.
• For weekly and fortnightly statements, the statement can be configured to start on any day of the week.

end_date

end_date cannot be configured separately from start_date and period. It is fixed by the relationship between start_date and period, e.g. a monthly Statement starting on the 5th must end of the 5th of the following month.

The end_date returned by the API is actually the day before the start_date of the next Statement for the same account. The exact moment of the cutoff between one Statement and the next occurs on midnight of start_date.

After the end_date, the Statement is closed, meaning that its contents are final and will not change. The statement emails will be sent the day after the end_date.