ICO

51% of control of this project is in the hands of Token holders.

THIS IS NOT A FINANCIAL OR GAMING PRODUCT. IT IS SOFTWARE MADE FOR THE BENEFIT OF INDUSTRY AND COMMERCE WHO WANT TO CONDUCT TRANSACTIONS PEER-TO-PEER AND DIRECT THIS PROJECT FOR THEIR OWN PURPOSES .

PROJECT DISCLOSURE DOCUMENT – “LETTER OF INTENT” FOR A TOKEN SALE OF BBILLER SMART CONTRACTS – “THE OFFER”. DATED XX AUGUST 2017 – AN INITIAL TOKEN OFFER (“ICO”)
Disclaimer:
1. This is not an Investment product. This is a crowdfunded project.
2. This is not a company share stock/derivative. It is a sale of a digital asset.
3. The purchase price of BBILLER digital tokens are pegged to the Australian Dollar and currently quoted in AUD.
4. GST is applicable on the sales of Digital Assets and applicable to Australian residents, for tax purposes only.
5. BBILLER tokens cannot be used to transmit money as payment for goods and services. See Token (“BILL”) instead.
6. bBiller websites and website applications are generally non-financial in scope, however our solution is KYC/AML compliant, were a financial act to occur (peer to peer).
7. BBILLER tokens offer no rights to company profits generated by the project, unless members propose that such should occur. As a member, you can.
8. BBILLER tokens are not designed or disingenuously devised to acquire stock or money, except as required by the owners of BBILLER tokens.
9. Final BBILLER and BILL tokens are denominated in the Asset class Digital Token ETH, and listed on various Exchanges for trading.

Start Date: TBA
End Date: TBA
Exchange Trading Date: TBA
Exchange: http://www.idex.market/

You must register to obtain the deposit contract address:

Distributed Autonomous Organisation – Capital Requirements

bBiller Pty Ltd seeks to raise $1,218,126.38AUD on the sale or disposal of 100,016,000 BBILLER tokens of which 12,500,000 Tokens at 0.012 cents each will complete a minimum viable product as specified in its whitepaper:
https://bbiller.com/wp-content/uploads/2017/07/Whitepaper-20170714-1250z.pdf

bBiller seeks to reduce the risk to purchasers by offering a full refund in the event that 12,500,000 tokens bought ($150,000AUD) fails to be reached between the start and end dates required to deliver a Minimum Viable Product (“MVP”).

bBiller seeks to offer an incentive to early adopters by offering a discount on the first 50,000,000 tokens which are quoted at 0.012AUD cents each in Round 1. The second round is priced at 0.02 cents per for 30,906,319 tokens on offer also.

bBiller has already sold 2,443,015 BBILLER tokens and received $14,865.18 AUD during its pre-sale period and will distribute those and a further 16,666,666 BBILLER tokens valued at $200,000.00AUD to management and for operations within 7 days prior to the commencement of the date in which the contract found at https://github.com/srowlison/bbiller/blob/master/src/bbiller.sol and deployed at the contract address shown at the how to buy page in this document and on the web page https://bbiller.com/ico.

Voting Rights

BBILLER token holders rights are to propose and vote by:
1. Requesting access to https://github.com/srowlison/bbiller
2. Execute their voting rights by calling this function from their wallet:

Function vote(uint256 _gitHubId, bool _inFavour).

Dividends

Members may petition the company that it pay a dividend by raising a proposal no more than every 12 months or earlier if agreed by way of an alternative proposal issued by members. bBiller will prioritise profits as follows:
1. Pay all expenses, taxes and charges
2. Account for liabilities and assets by making provisions in accordance with financial best practices
3. Make counter proposes for the goodwill of the company and its largest owner
4. Argument the use of forward estimating tools to auction the net profit after tax contribution. The following inputs will be used to scale votes and determine distribution:

a. Number of Tokens owned by members,
b. Number of Tokens in circulation,
c. Use the Mean Distribution curve of Votes counted, and;
d. Apply Predictive Oracles as it sees fit.

How to Buy
Send ETH to the contract address between the published dates. The contract address is only available to participants who have registered.

Notes
1. Only send ETH from an address you control.
2. All sales are final

How to Exit
Tokens can be exchanged wherever they are accepted. We recommend distributed exchange http://www.idex.market/

How to get a refund:
Invoke: function refund(address _to) at the end of the ICO end date. Refunds will not be given if more than 12,500,000 tokens are sold for ETH prior to the ICO end date.

Funds from operations
bBiller BILL tokens are used by end users and comprise:

1. Ethereum GAS used to fuel the supply chain transaction,
2. Gross Profit Margin retained by the company and held at the gross income address as stipulated.

Gross Income is sent to the BBILLER account address for dividend distribution by, to and for its members, i.e. holders of BBILLER tokens. BILL tokens can be purchased from bBiller, its distributors or from exchanges where the token is traded.

Forward Looking Statement
BBILLER funds received for a production ready system shall either be deemed by members as:
1. In-sufficient for purposes,
2. Sufficient for purposes to return value to members and end users broadly,
3. Another scheme.
In the event that 1. is proven, BBILLER members may propose that they be topped up pro-rata and the token re-capitalised.

A Distributed Wallet for Supply Chain Automation

The bBILLER ICO will fund the next generation of the Distributed Ledger Technology revolution sweeping the globe. bBILLER ICO is your opportunity to gain a stake NOW in the growth to maturity of the virtual currency payment processing market as it emerges from the early adopter stage to become the standard operating environment for major corporations, governments, and institutions worldwide.

Who Should Buy at their own risk?

• Financial Accounting Supply Chain management and enterprise resource planners from the Fiat world
• Hedge fund managers and institutional investors from Wall Street, the city of Dublin and Munich
• Strategic coin investors with timings and tactics
• Speculators

bBILLER is meeting current and future business needs for Distributed Ledger Technology and virtual currency processing with strategic roadmaps and technology plans which will deliver a peer-to-peer supply chain application based on the Ethereum blockchain based on International Standards.

Executive Summary
As a concept, the blockchain has enabled secure decentralized transactions between parties without the involvement of intermediaries or third parties. When applied to virtual cryptocurrencies, value can be exchanged directly between parties who agree on the worth of tokens being conveyed, with only a simple digital ledger tracking the amounts involved.

This lack of transparency is not suitable in a business context where it is necessary to enforce identity authentication and provide the ability to audit business properties of transactions. Concepts of AML (Anti-Money Laundering) and KYC (Know Your Customer) are front-and-centre in efforts to prevent money laundering and the financing of terror. Using an open international standard XML vocabulary to express those business properties of documents such as purchase orders, transportation orders, transportation events and invoices presents and records this information to and for all involved in a manner not biased to any application, vendor or platform.

By cutting out the middle man, that is, by disintermediating the process, a buyer can post to the blockchain an order for goods complete with the payment for those goods, their shipping and the processing of the paperwork.
Upon a preconditioned fulfillment expressed as a smart contract, after as few or as many steps as required, the seller and other authorized parties involved in the process can instantly and automatically receive their portion of the payment off of the blockchain.

All parties involved can access the blockchain directly or through their individual representative service provision organizations, but at no time is there any kind of a centralized membership organization, clearing house organization, process execution entity or other third party that might interfere with the swift progress of changes in state of the procurement process. A marketplace of such service providers is anticipated to grow quickly as organizations recognize the business opportunity offering to constituencies of users the service of standardized access to the blockchain for private or colloquial document standards and differing interfaces.

The http://bBiller.com project is implementing just such a process, using the ISO/IEC 19845:2015 OASIS Universal Business Language 2.1 internationally-standardized specification (http://docs.oasis-open.org/ubl/UBL-2.1.html, http://www.iso.org/iso/catalogue_detail.htm?csnumber=66370) for the XML expression of the business properties of procurement and transportation supply chain documents.

Historical approach to supply chain processes

The historical business supply chain choreography has been played out over a long history of doing business in an intermediated manner.
Manufacturers work through sellers who offer the goods. Buyer’s orders trigger shipments which, in turn, trigger invoices which, in turn, trigger payments. Those payments may take a long while to fulfill. Buyers take the full trade credit period of time while suppliers are out their manufacturing and shipping costs.
Sellers take their share and the manufacturer is left with the rest when they finally get their money.
This is the way it has worked for a long time. Expensive EDI (Electronic Data Interchange) systems and networks are available to large companies to ensure the process is performed in a secure and rapid fashion with formalized messages. EDI standards exist for the assembly of such messages, but the messages themselves are as varied as there are users of EDI. And the cost of EDI is often too much to bear for MSMEs (Micro-, Small- and Medium-sized Enterprises), thus keeping a majority of the players out of the dance of formal business electronic commerce.

The Internet provides a platform on which new e-commerce systems are being built in order to better include MSMEs.

For a while, the “single window” concept has been very popular, but it is falling out of favour for newer “open network” system architectures. It helps to briefly compare the two by considering how a document, say an order, goes from the buyer to the manufacturer/seller.

Single-window implementations are characterized by what is termed a “3-corner model” of the interactions of participants. In such a model a centralized party is the intermediary between the buyer and the seller for both the information interchange and perhaps, even, the payments. It is the centralized party defining, implementing and presenting the single window for all participants to work through. The documents may be open, or they may be proprietary, as the provider doesn’t have much incentive to use open specifications.

Inevitably, however, there will be outlier organizations unable to use the single window for a myriad of possible reasons. Perhaps they don’t have connectivity, or perhaps they cannot process the document formats.

Contrast that to the “4-corner model” where all parties access each other through their own respective “access point” service. An example of such a network is http://PEPPOL.eu (Pan-European Public Procurement Online) initially created for European government procurement, but there has long been more business-to-business traffic on the platform than there is for business-to-government and it is growing rapidly.

The access point is certified to meet a defined service level agreement incorporating the obligation to use open protocols and open document standards, even if the users they service are not using the same document standards. Where an outlier exists they can buy or build their own access point to the open network precisely because it is open.

The PEPPOL platform can be engaged in many ways for the same business task, based on the needs of users. Two simple examples are “Invoice only” and “Invoice in response to order”. These are considered different “profiles” of the choreography of the supply-chain process, with different choreographies and differing content subsets of the standardized documents. Access point providers must implement the profiles needed by their clients.

Certification and management is still done by a central party, the OpenPEPPOL organization in this example, but that party isn’t an intermediary in the path between buyer and seller. Hundreds of access points are coming to market to service different constituencies of users. And, of course, banks are still involved as intermediaries for payments.
So even if the document exchange can be disintermediated, there are still some intermediaries involved and it is still centralized around the certification of the access points.

The evolution of document format standards
There is no obligation on the part of a central provider to use open standards, though of course doing so might open up the access to more parties.

Pertinent to PEPPOL (and similar networks as in Australia) and other national networks (such as in Peru and Colombia for two examples) and in many other countries, work has been done since 2001 to create a family of formalized and internationally-standardized XML-based supply-chain documents for open use over the Internet.

Systems and communities needing to embrace MSMEs by providing lower-cost implementations of the process have adopted the ISO/IEC 19845:2015 specification, developed as OASIS UBL (Universal Business Language) 2.1 There are 65 different XML document types in UBL 2.1 for processes such as procurement (tendering and presentment) and transportation.

UBL 2.2 is under development with a total of 81 document types. UBL 2.3 is planned to have yet more document types related to payment to streamline connectivity with ISO 20022-based financial systems.

What UBL brings to the table is a suite of commonly-accepted business semantics in the form of a common library of structured constructs. These business objects are then assembled into document types to represent the collection of information pertinent to a particular need for expression of a business transaction. Such is the objective of anyone designing a document format for the exchange of business information. So having a published and standardized collection of documents precludes the need to create one’s own.

The choice of using XML for the expression of UBL leverages the long-used XML stack of technologies from validation through to publishing. Rumours of XML’s demise are greatly exaggerated. XML is a platform-, application- and vendor-independent format for representing information using semantic labels on marked-up content. No presumptions are made regarding any application’s internal representation of the information in the markup. Such is ideal for arm’s-length interoperability between the known and unknown systems of trading partners. It can be verbose, but in doing so it can be unambiguous when designed properly, as the effort has been made to do so for UBL.

Contrast XML to the JSON role of serializing in-memory programming data structures in compact expressions. Such brevity is critically important in user interface interactions between applications and browsers. Indeed, JSON is named the JavaScript Object Notation, designed for quickly conveying the information between logic and dynamic presentation.

Finally, with the growing acceptance of UBL in a number of public projects and unpublished private uses of UBL within organizations both global and local, the skills for working with UBL are useful to attain and beneficial to leverage. The prevalence of UBL brings these standardized documents to the attention of more people responsible for understanding business messages, such as auditors. Such has always been difficult with colloquial document formats and the endless variant EDI utilizations of its message-building rules.

The blockchain difference
For many traditional processes the blockchain provides a new opportunity to decentralize the access and disintermediate the process entirely. Initially such was exploited for the simple but effective peer-to-peer exchange of value. Pertinent to traditional business-related applications, blockchain technology, also known as DLT (Digital Ledger Technology), features open access (a distributed peer-to-peer network), settlement (the instant exchange of value) and immutability of the content (a permanent record).

The security of the blockchain and the appropriateness of the exchange of value using cryptocurrencies are still up for debate and will probably never be accepted by all. Nevertheless, there are people today accepting of the risks and they are enjoying the benefits provided by the technology. And these people want to leverage the blockchain to do business, and in some cases are building their own businesses on top of blockchain technology so that the business can realize the perceived benefits of cryptocurrencies. But people have different paper-trail expectations than business does. The documentation of business has evolved ever since business started being transacted. And, so, for business to properly and effectively work on the blockchain, the documentation of business becomes an incredibly important aspect of the implementation.

Documents can be stored on blockchains in an open or an encrypted fashion for public or private consumption. In turn, a smart contract can act on the content of those documents in order to advance the process through the defined state transitions of different aspects of the process. Payment can be made up front at the start of the process and then released automatically when conditions are met at the end of the process.

Consider an illustrative example of how the blockchain approach would be able to incorporate a number of the UBL documents in a detailed profile choreography:

The steps of this illustrative idealized profile are as follows, and do not include tendering or catalogue components:

A. The buyer adds to the blockchain the UBL Order for goods and their cost and the shipping charges as published by the seller, to be released subject to the successful receipt of goods.

B. The seller needs to determine the shipping logistics and supplier and so issues a UBL Transport Service Description Request with the details.

C. Logistics providers competitively respond with a UBL Transport Service Description outlining how each will be meeting the request, the UBL Transport Execution Plan describing the details of the shipment process and the UBL Goods Item Itinerary detailing the contents of the shipments and consignments.

D. The seller selects a logistics provider and responds by adding to the blockchain a UBL Order for freight service and its payment.

E. The logistics provider posts to the blockchain a UBL Despatch Advice announcing the despatch of the shipment.

F. At any time the seller may request an aggregated status by posting a UBL Transport Progress Status Request.

G. The logistics provider responds by posting to the blockchain a UBL Transport Progress Status with the latest information.

H. Through the transportation process itself, it is possible for participants to post to the blockchain their specific changes in status using the UBL Transportation Status document.

I. The goods having been delivered triggers a UBL Receipt Advice being added to the blockchain. This could be triggered automatically by the buyer signing for the delivery through a device presented by the shipper, so as not to allow the buyer to delay.

J. With the shipment made the logistics provider can add the UBL Freight Invoice reflecting the actual incurred costs.

K. This automatically triggers the freight expense to be released into the hands of the logistics provider and an acknowledgement using a UBL Application Response. Any overpayment would stay in the blockchain.

L. At this point the seller can issue the UBL Invoice reflecting the cost of the actual goods delivered and the amount of the shipping the seller wants to charge the buyer.

M. This automatically triggers the buyer’s goods and shipping costs to be released into the hands of the seller and an acknowledgement using a UBL Application Response. Any overpayment would be returned to the buyer.

A marketplace for blockchain service providers
The blockchain also opens up a marketplace for service providers to meet the needs of users who want to use the available profiles but don’t have the technology or the know-how to meet the technical requirements.

Figure 3. Blockchain access methods

Focusing on two trading partners, they use different access points to access the system. The access point is responsible for converting the user data (if necessary) to UBL XML as a service to their constituency of users.

The business rule validation step is the face of any such service. It is tailored to the business scenario within which the access points are providing their service. This checks code lists and contents as configured for the business scenario. If anything is amiss the XML is rejected. If everything is acceptable, the XML is posted to a blockchain (by default encrypted but it can be openly legible if desired), translated to the data structures of SOL, the Solidity programming language, and forwarded for execution.

The business process execution is the heart of any such service, with the state machine acting on the content of the business document as it is expressed in SOL. It progresses the process without having to check a lot (if any) of the user tailoring because that has been checked by the business rule interface.

With this separation, different business scenarios can be built on top of the one process engine.
A marketplace of service providers is created as blockchain-savvy companies go to the market to offer their service of connecting their clients to the blockchain.

Different communities of users will be attracted to the services of different providers. A user might even implement their own access point to the system if they have the capability and don’t need a service provider. The interface between users and access points is private between the two parties, and it need not be UBL, though it could very well be UBL. When it isn’t UBL the access point would need to perform the appropriate conversions in both directions.

Tasks such as a print rendering of a UBL document can be done from the XML as part of the business customization (with stylesheets, perhaps customized with logos, provided by the access point).

Moreover, leveraging international standards such as UBL will empower and entice to the blockchain any existing service providers already familiar with and implementing UBL in projects such as PEPPOL.

Conclusion
There is value in disintermediating the supply-chain process by taking out the middle men of finance and process.

There is value in the instant disbursement of payments to all parties involved as and when obligations are being met. Timely reporting of intermediate steps of the process improves all parties’ abilities to plan ahead.

The blockchain and cryptocurrencies already implement an ad-hoc value exchange between sender and receiver without any paper trail (very attractive to many) in a decentralized and disintermediated fashion.
These same benefits from studying and applying the blockchain approach to the supply chain process will be attractive to organizations relying on formal document audit trails of the procurement and transportation process.

Using an internationally-standardized document format such as UBL for that audit trail leverages the investment in other projects that also use the same format, and equips the resources for development of future projects needing the same documents.

And international standards evolve to meet real-world requirements, but only with the active involvement of those who will be served by the work products. Increased participation in the international committees is always welcome by committee members. More hands make for light work. Getting in on the design of document formats opens opportunities to influence the work products published for everyone to use openly and freely.

High Level Design – Distributed Client Wallet

The runtime client is an Ethereum wallet which securely stores ether and can deploy the BILL contract and store the populated UBL XML document in https://ipfs.io/

The parameters required or optional to execute the smart contract for a transaction are passed in from the XML document at the client.

The client will be listening for responses from any party and its job is to match the information in the documents received with those in progress i.e. not completed. In process documents are related by transaction ID and linked to the Ethereum smart contract ID populated there from.
On receipt of a response, the client gets updates which change the state variables in the BILL contract and because of these state changes executes code in the contract to do work, for example to release funds held in escrow or from the wallet, to supply chain parties.

Dashboards will show the state of running contracts and document status. Documents and schemas are recoverable from ipfs.

Low Level Design – Supply Chain Configuration Tool
The relationship between a BILL contract interface and a transaction event comprising one or more international standard ISO/IEC 19845 UBL documents and their lowest level elements will be described by cardinality given by the end user generating their supply chain dependencies. This configuration tool and the Distributed Client Wallet Software are modelled here:

See Mockup: http://52.173.188.232/XMLProfileGenerationTool/Mockup-1.html (unstable)

Non-Functional Requirements

A single BILL token is an Ethereum Smart Contract which will be developed during the MVP. The purpose of the contract is to manage the state of a transaction in a supply chain process given by an end user. Executions of the process requires one BILL token at a given price point dependent on market demand.

Landing Page for Configuration Tool

This page details the MVP functional requirements:

http://bbiller.azurewebsites.net/

From this page end users will be able to download the Distributed Client Wallet software and Configuration Tool in one package. This benefit will be further exploited in the production build.

Need an Ethereum Wallet? Do not sent ETH from an exchange.
Buy Ethereum to purchase BBILLER 

Error: No data from the server!Data by CryptoCompare API

Live Help?

Telegram: +61 473 414 070
Signal: +61 473 414 070
Whatsapp: +61 473 414 070

Useful Links
Ledger Wallet protects your Ethereum