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.

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. This has a number of benefits:

• You can select top-tier buyers to offer extended payment terms to, whilst keeping other buyers on standard terms.
• Removing the choice of payment terms from each checkout means less to think about for Buyers.
• 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 Billing Accounts

Once enabled for your platform by your Customer Success Manager, Billing Accounts can be configured in different ways.

The basic steps of the manual process are:

1. Create a Billing Account
2. Use the organisations field to configure which Organisations should have their Captures and Refunds appear on the Billing Accounts' statements.

It's also possible for organisations to automatically be added to billing accounts.

Configuration Method	Automated	Manual
Use case	All buyers are to be on billing accounts	Some or all buyers are on billing accounts
Supported implementation types	Intent API	Full API
How it works	Default Billing Account terms should be agreed with your customer success manager. Organisations are automatically added to a Buyer company-wide Billing Account with these default terms. Buyers could manually be put onto different terms on a case by case basis.	Billing accounts must be created, and organisations added to them, by API or in the Merchant Dashboard.
Consolidation of organisations	All organisations associated with a company are automatically consolidated onto one billing account.	You can choose to put organisations onto different billing accounts, or consolidate them onto the same one.

To configure billing accounts by API, see in the API reference Billing Accounts. Billing Account options are shown in the merchant dashboard on the Buyer page

Manual Billing Account configuration

If you are manually configuring billing accounts, make sure all organisations associated with a company get added if that is your intention. See Advanced: Organisations and Consolidated Statements.

Periods and Dates

Billing Accounts can be set up to create Statements

• Weekly,
• Fortnightly,
• Monthly or
• n times per month (eg. 3 statements per month)

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

You can create two billing accounts with the same period and different due dates. It may be that you wish to offer some of your Buyers monthly statements with 30 day terms, whilst offering a premium tier of Buyers 60 day terms.

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.

Advanced: 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.

If the buyer’s preference is to receive separate Statements for each site, then create multiple Billing Accounts and put Organisations separately on each (see "Not Consolidated" below).

On the other hand, to issue one Statement for all the company's Organisations, put all the Organisations on one Billing Account (see "Consolidated" in the figure below). It is still possible to distinguish different Organisations on a consolidated statement.

Use the organisation.name field to easily identify each site or branch of the Buyers' company.

It may also be that within one site, there are particular groups of users that should recieve their own statements. In this case, you can create an Organisation for each of these groups, and give them their own Billing Accounts.

Credit Limits apply at Company level

Credit limits are assigned to Companies rather than Organisations or Billing Accounts. Let's say there exists Organisations A and B. If Organisation A places an order, this will consume the remaining limit for Organisation B too.

Emails

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

Changing the terms of a Billing Account

Top-tier buyers

You can extend the payment terms for your top-tier buyers' Billing Accounts, whilst leaving other buyers on standard terms.

It might be that:

• you want to extend the payment terms for a particular segment of Buyers without offering this to all buyers, or
• 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 possible to update the Billing Account terms with a PATCH command or in the Merchant Dashboard.

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.

Advanced: Associating Documents with Statements

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

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

We can email the invoice and credit note documents to Buyers along with the close of their statement. 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. To do this:

1. Apply the Capture or Refund Deferred Payment Event
2. Store the Deferred Payment Event id from the response
3. When uploading the OrderDocument, supply the Post Sale Event id in the deferred_payment_event OrderDocument field.

Voids

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

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 possible to update the Billing Account Terms with an http PATCH request on the billing account endpoint or in the Merchant Dashboard.

Statements

Statements are issued on a periodic basis for each Billing Account.

Statement identifiers

Each statement has a static public reference that pertains to the Billing Account. This is to encourage buyers to repay with that identifier as a reference in their bank transfers.

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.