Whitepaper

A De-centralised Accounting System for Commerce and

Industry: 14th July 2017. 12:00 UTC.
Written by Stephen Rowlison & G. Ken Holman

1 20170714-1250z
Contents
Whitepaper............................................................................................................................................1
Introduc8on...........................................................................................................................................3
Un8l the advent of the Blockchain, we leC it up to others to connect us with our customers and
suppliers. bBiller brings trust and distributed reconcilia8on of nancial records..............................3
a.Data Exchange.............................................................................................................................3
b.Payments....................................................................................................................................3
c.Enhanced seNlement op8ons.....................................................................................................3
d.Plug-in devices............................................................................................................................3
e.No bank needed..........................................................................................................................4
Target markets.......................................................................................................................................4
Problem Deni8on.................................................................................................................................4
Solu8on Summary.................................................................................................................................5
Tradi8onal Billing...............................................................................................................................6
Use cases...........................................................................................................................................6
Billing collabora8on plaSorm illustra8ons.........................................................................................6
Conclusion.............................................................................................................................................8

2 20170714-1250z
Introduction
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:

a. Data Exchange
Customers and suppliers get Instant status updates: Reduces enquires and data entry

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

c. Enhanced se5lement op8ons

Prove payment, escrow and trade finance

3 20170714-1250z
 d. Plug-in devices
IoT ready

e. 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 Programmers 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 financiers 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.

4 20170714-1250z
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
suppliers 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 VATValue Added
Taxsuperimposed).

5 20170714-1250z
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:

Packaging
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

a. 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).

2. Raise an invoice related to the purchase order Supplier

a. 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.

3. Pay a suppliers invoice Financier

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

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

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

6 20170714-1250z
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.

2. 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.

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

4. 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.

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

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

7. The despatch advice provides for two situations:

a. 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

b. 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.

c. 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.

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

i. Full despatchadvising 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.

ii. Partial despatchadvising 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.

iii. 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.

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

7 20170714-1250z
 v. Within a despatch advice, an item may also indicate the country of origin
and the hazardous nature of the item.

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

i. 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

ii. Indication of receipt by receipt lines annotated by transport handling unit,

one-to-one with the despatch advice as detailed by the seller party.

iii. 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.

8. Order Change
a. 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.

9. Order Cancellation
a. 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.

10. Part Payments

a. The contracts support part payments.

b. 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.

c. 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.

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

Conclusion
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.

8 20170714-1250z