Below is a description of a free protocol which enables peer-to-peer
invoicing at zero transaction cost. The sender can send invoices at
zero cost and the receiver can read the invoice data into their
I'd like to hear your comments!
--- begin of document ---
THE SIMPLE INVOICING PROTOCOL - REQUEST FOR COMMENTS
The design goals of the Simple Invoicing Protocol (SINV) are:
- Simplicity and ease of implementation and use
- Unambiguous protocol
- The receiver can read all essential information automatically into
- Peer-to-peer protocol, no hubs or exchanges needed
- SPAM protection
- Invoices can even be sent by typing them manually
Invoices are sent as e-mail messages. Both the receiver and sender
have an e-mail address. The receiving mailbox must be dedicated to
only SINV messages.
2. BASIC PRINCIPLE
First the invoice sender must send a PARTNER message which contains
information of the sender. The receiver must check the information
and create an account for the sender - either manually or
(semi)automatically. The receiver must reply to the sender when the
was created or if the registration is rejected.
Registered senders can then send INVOICE messages. The receiver MUST
to an INVOICE message whether it was successfully parsed and invoice
processing in the receiving organization has been started. The
SHOULD inform the sender when the invoice is paid or if there are
3. MODIFICATIONS NEEDED FOR EXISTING SYSTEMS
The sender must modify the invoicing system to send PARTNER and
messages via e-mail.
The receiver must dedicate a mailbox for incoming invoices. The
needs a program which can read the mailbox (via POP3 or IMAP for
and parse the PARTNER and INVOICE messages. For each PARTNER message
work flow for a new account must be started. For each INVOICE
a work flow for approving a purchase invoice must be started.
4. MESSAGE SYNTAX
A message contains elements. An element contains a tag which begins
period, such as .INVOICE. All tags are in UPPER CASE.
An element may contain a value. The value might be only one line, in
case in can be typed after the tag, separated by white space. If the
value contains many lines, the lines can be typed after the tag. The
MUST NOT contain a line which begins with a dot.
All dates are represented as YYYYMMDD. All numbers are represented
digits with a leading sign, digits, decimal point (dot) and
digits. The sign and decimal part (the dot and digits) are optional.
5. PARTNER MESSAGE
Starts a partner message and indicates the version of the protocol.
Identifies a partner. Partners are identified by unique e-mail
Identifier of the company given by local authorities. In Finland
Name of the company.
Address of the company. Usually multiple lines. Format according to
Contact e-mail if diferent from ID.
Bank account in IBAN format.
Name of the person who should approve the partner account.
Ends a PARTNER message.
.NAME Dot Com Consulting
Solvikinkatu 11 B 28
.ADRESSEE Helena Takalo
6. INVOICE MESSAGE
6.1. INVOICE HEADER
Starts the INVOICE message and indicates the version of the
Unique identifier of the invoice - the invoice number.
OPTIONAL code that is returned via bank when this invoice is paid.
Viitenumero in Finland.
Identifies the sending PARTNER.
Identified the receiving PARTNER.
Date of the invoice.
Three-character currency code.
Name of the person who should check or approve the invoice.
Customer's project number or any accounting information
Ends the INVOICE message.
6.2. INVOICE ROW
Starts a new row in the invoice. All amounts are in ROWs.
One-line description of the item in this row.
OPTIONAL how many items in this row?
OPTIONAL unit for .COUNT.
Amount without VAT.
OPTIONAL Discount amount.
Total to be paid for this row.
Ends a ROW.
.ADRESSEE Helena Takalo
.DESCRIPTION Invoicing seminar after Easter
.DESCRIPTION Train ticket a 33.60
The total amount to be paid is 592.98, and it has to be paid on 3rd
2009 to the account that belongs for " firstname.lastname@example.org".
actual account number was given by a preceding PARTNER message.
--- end of document ---