A De-centralised Accounting System for Commerce and Industry.
PDF Whitepaper – Free Download
Written by Stephen Rowlison & G. Ken Holman

Until the advent of the Blockchain, we left it up to others to connect us with our customers and suppliers. bBiller brings trust and distributed reconciliation of financial records.

The bBiller system is for anyone who wants to take control of their business processes concerning accounts payables and receivables (money in/ money out). Additionally, there is the opportunity for token holders whether they be guiding the project or become customers. Based on quality open and international standards, the largest and most detailed of processes, bBiller Supply Chain Automation, will significantly disrupt established centralised providers and regulators in all markets.

bBiller has already demonstrated its understanding on the complexities of document exchange, smart contract design and deployment. With our in-depth knowledge of business process design and encryption technology, bBiller has conceived a unique model on multiple levels that reduces risk and ensure product delivery through community collaboration on a fee for membership basis and a fee for service basis.

Our fee-for-membership model gives autonomous rights to BBILLER token holders to direct the project. Using democratic voting, where a member with 1 vote has as much influence as a member with 100 or more votes, bBiller offers unprecedented opportunity in this billion-dollar market.

Considering the number of accounting packages and banks that support the process of getting paid, only bBiller offers an open and extensive range of transactions covering almost any use case in procurement.

bBiller supported documents, transactions and processes:

  • Connector.

    Data Exchange

    Customers and suppliers get Instant status updates: Reduces enquires and data entry

  • Connector.


    Pay in any currency, use crypto-currencies for instant settlement

  • Connector.

    Enhanced Settlement Options

    Prove payment, escrow and trade finance

  • Connector.

    Plug in Devices

    IoT ready

  • Connector.

    No Bank Needed

    Send money Peer to Peer: No need to reconcile accounts. This is not a centralised system.

Target markets

The heart of bBiller is an Application Programmer’s Interface (API) to a blockchain-based platform of smart contracts. The basis of the API is the customer-tailored use of OASIS Universal Business Language (UBL) version 2.1 documents that are internationally standardised as ISO/IEC 19845:2015. The smart contracts on the blockchain provide all the features of security and immutability that are delivered by this new technology.

Customers of the bBiller platform are:

Service providers / software vendors – These customers use the bBiller API to prepare, sign and send UBL documents and associated smart contracts on behalf of their customers and users. Service providers can enable their customers’ back-end procurement and transportation logistics systems to leverage the platform. Software vendors can augment their product offerings with a ready-made supply-chain process service. Service providers and software vendors can be considered wholesalers of the bBiller platform to their own end-user constituencies.

End users – Employing our own API, bBiller provides other end users the bBiller supply chain portal directly using a web interface. This will be useful to many as an alternative to buying or using a centralised supply-chain system.

Both types of users require bBiller BILL tokens to operate the system. These tokens contain enough gas and margin to support various processes designed by end users and service providers.

This business also earns revenue from service engagements and premium support. Enterprise tools for contracts are slated for introduction in 2018.

Problem Definition

The problem of centralised systems is that they are not linked programmatically to the execution of a contract between a customer, supplier and financier’s terms and conditions for delivery of goods and services and subsequent payments. This disconnect is the reason for the high cost to business, the public sector and regulators worldwide.

In the current traditional billing model, a request is received from the supplier/customer to issue a purchase order. The order contains various terms and conditions for the delivery of the service and subsequent payment.

The supplier raises an invoice against the purchase order and sends it to the customer. The customer matches the invoice to the purchase order and awaits delivery of the goods and services or implied terms are accepted, the payment is made to the supplier. Various exceptions and other conditions impact this process such as transport costs, taxes, charges, late fees etc. Costs are incurred in the many exceptions created owing to the differences in systems used between the participants.

Negotiation and enforcement are typically simple relationship issues or complex legal outcomes concerning non-delivery or non-payment.

Suppliers want to operate within the terms of the purchase order and receive prompt payment, however customers typically hold back payments on the grounds of wanting to better manage liquidity.

Customers want the goods or services to be within the stated tolerances proposed by the supplier and expect prompt delivery without wanting to deliberately hold back payments.

Investors want to fund the cashflow of supplier invoices, thus improving the liquidity of a supplier’s cash flows.

Business owners of all these roles want to reduce the costs and exceptions.

Solution Summary

The production system will generate smart contracts for end users’ supply chain requirements based on the vector between UBL documents and their state machine requirements provided for by Ethereum. Users choose from pre-configured business process definitions or from customised and tailored definitions created using premium services.

Increased liquidity for MSMEs means less time spent in billing collaboration e.g., following-up unpaid invoices, elimination of duplicate invoices, less burden in the bookkeeping function, tax calculation and financial reporting. Elimination of centralised double entry book-keeping system is the single most important goal to which this project makes a valuable contribution.

An invoice defines the financial consequences of a business transaction. The invoice is normally issued on the basis of one despatch event triggering one invoice. An invoice may also be issued for pre-payment on a whole or partial basis. The possibilities include but are not limited to:

Prepayment invoice (payment expected)
• Pro-forma invoice (pre-despatch advice, payment not expected)
• Normal invoice, on despatch for despatched items
• Invoice after return of receipt advice

The invoice only contains the information that is necessary for invoicing purposes. It does not reiterate any information already established in the order, order change, order response, despatch advice, or receipt advice that is not necessary when invoicing. If necessary, the invoice refers to the order, despatch advice, or receipt advice by a reference for those documents.
The invoice allows for compound taxes, the sequence of calculation being implied by the sequence of information repeated in the data stream (e.g., Energy tax, with VAT—Value Added Tax—superimposed).

Charges may be specified either as a lump sum or by percentage applied to the whole invoice value prior to calculation of taxes. Such charges cover:

• Delivery/postage
• Freight
• Documentation

Each invoice line refers to any related order line(s) and may also refer to the despatch line.


Traditional Billing

Traditional billing is where the supplier invoices the customer when the goods are delivered or the services are provided. In this case, the invoice may be created at the time of despatch or when the delivery party acknowledges that the goods have been received (using a receipt advice).

When there are discrepancies between the despatch advice, receipt advice, or invoice and the goods actually received, or the goods are rejected for quality reasons, the customer may send an application response or a debit note to the supplier. The supplier may then issue a credit note or another invoice as required. A credit note or debit note may also be issued in the case of retrospective price change.

Credit notes or debit notes may be also issued after the billing collaboration (as part of the payment collaboration).

Use cases

Customers and suppliers may collaborate on our fee-for-service platform. The system would allow for the following use cases:

  1. Issue a purchase order contract – Customer

    1. The purchase order document is digitally signed. A smart contract is broadcast on the network which refers to the digital signature of the contract (Proof of existence).

  1. Raise an invoice related to the purchase order – Supplier

    1. reference to the purchase order is associated with the raised invoice. The smart contract in 1. Above records the state of the contract as invoice raised but unpaid.

  1. Pay a supplier’s invoice – Financier

  1. The financier replaces the customer role of payer and pays the supplier once the goods or services are delivered.

  2. The funds are loaned to the supplier and released less the financiers margin.

  3. The smart contract would ensure that the funds collected from the Customer are paid to the Financier.

Billing collaboration platform illustrations

  1. The purpose of the billing collaboration platform is to bring suppliers, customers and financiers together. The platform owner “bbiller.com” or its licensees would provide a web site for the purposes of registering participants and in assisting in the processing of orders and smart contracts.

  1. The portal platform would allow financiers to review transaction history between the suppliers and customers, and based on their risk tolerances from data collected, historically so they can choose which supplier invoices they will own and pay.

  1. An API would allow developers to build interfaces into the platform. The developer API could be subscribed to for automatic selection and funding.

  1. Transaction logs and the status of contracts would be visible to participates based on their role. Digital currency payment transactions would show on the blockchain.

  1. Debit and credit notes raised by way of exception.

  1. Purchase order Invoices would interact with despatch advice and receipt advice notifications.

  1. The despatch advice provides for two situations:

    1. Organisation of the delivery set of items by transport handling unit(s) so that the receiver can check the transport handling unit and then the contained items

    1. Quantities of the same item on the same order line may be separated into different transport handling units and hence appear on separate despatch lines within a transport handling unit.

    1. Organisation of the delivery set of items by despatch line, annotated by the transport handling unit in which they are placed, to facilitate checking against the order. For convenience, any order line split over multiple transport handling units will result in a despatch line for each transport handling unit they are contained in.

    1. Additionally, in either case, the despatch advice may advise

      1. Full despatch—advising the recipient and/or buyer that all the items on the order will be, or are being, delivered in one complete consignment on a given date.

      1. Partial despatch—advising the recipient and/or buyer that the items on the order will be, or are being, partially delivered in a consignment on a given date.

      1. Despatch lines of the despatch advice need not correspond one-to-one with order lines, and are linked by a reference. The information structure of the despatch advice may result in multiple despatch lines from one order line.

      1. Equally, partial despatch may result in some order lines not being matched by any line in a despatch advice.

      1. Within a despatch advice, an item may also indicate the country of origin and the hazardous nature of the item.

    1. The receipt advice provides for two situations. For ease of processing claimed receipt against claimed delivery, it must be organised in the same way as the corresponding despatch advice:

      1. Indication of receipt by transport handling unit(s) and contained receipt lines one-to-one with the despatch advice as detailed by the seller party, or

      1. Indication of receipt by receipt lines annotated by transport handling unit, one-to-one with the despatch advice as detailed by the seller party.

      1. The receipt advice allows the delivery party to state any shortages from the claimed despatch quantity and to state any quantities rejected for a given reason.

  1. Order Change

    1. When a request for a change to an order is received, the smart contract will be cancelled and a new contract created. Any funds in the initial contract are returned to the originator.

  1. Order Cancellation

    1. When a request for a cancelation of an order is received, the smart contract will be cancelled. Any funds in the contract is returned to the originator.

  1. Part Payments

    1. The contracts support part payments.

    2. The order may specify allowance and charge instructions (e.g., freight, documentation, etc.) that identify the type of charge and who pays which charges. The order may be placed “on account” against a trading credit account held by the seller, or against a credit/debit card account, or against a direct debit agreement.

    3. The Order allows for an overall currency defining a default for all pricing and also a specific currency to be used for Invoicing. Within an order, additional currencies may
      be specified both for individual item pricing and for any allowances or charges.

    1. Ideally a digital currency would be used, prices may be quoted in fiat, but settlement would occur with a digital currency.


The bBiller platform offers an attractive solution to both small and large decentralised document and billing platform. bBiller tools are being designed to offer open flexibility in process design and data sharing via the blockchain. BBILLER tokens holders have direct access to driving the project for their specific financial applications through decentralised blockchain provider bBiller Pty Ltd.