Network Working Group J. Jaakola Internet-Draft Intended Status: Standards Track November 9, 2009 Expires: May 13, 2010 The Simple Invoicing Protocol draft-jaakola-simple-invoicing-protocol-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on May 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This memo specifies a protocol for transferring invoices automatically between companies. The receiver can read invoice data automatically into accounts payables and possibly into approval work flow. This eliminates the costly and error-prone manual typing of invoice data. Main design goal was simplicity in order to make implementation easy. The parties involved identify themselves using e-mail addresses, which makes addressing simple and flexible. Table of Contents 1. INTRODUCTION 2. BASIC PRINCIPLE 3. MODIFICATIONS NEEDED FOR EXISTING SYSTEMS 4. MESSAGE SYNTAX 5. PARTNER MESSAGE 5.1. TAGS 5.2. EXAMPLE 6. INVOICE MESSAGE 6.1. INVOICE HEADER 6.2. INVOICE ROW 6.3. EXAMPLE 7. SECURITY CONSIDERATIONS 1. INTRODUCTION This protocol is intended to allow sending invoices automatically from invoicing systems to accounts payables and approval work flow systems. 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 their systems - 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 must have an e-mail address. The receiving mailbox must be dedicated to handle only SINV messages. 2. BASIC PRINCIPLE First the invoice sender must send a PARTNER message which contains basic information of the sender. The receiver must check the information manually and create an account for the sender - either manually or (semi)automatically. The receiver must reply to the sender when the account was created or if the registration is rejected. Registered senders can then send INVOICE messages. The receiver MUST reply to an INVOICE message whether it was successfully parsed and invoice processing in the receiving organization has been started. The receiver SHOULD inform the sender when the invoice is paid or if there are problems. 3. MODIFICATIONS NEEDED FOR EXISTING SYSTEMS The sender must modify the invoicing system to send PARTNER and INVOICE messages via e-mail. The receiver must dedicate a mailbox for incoming invoices. The receiver needs a program which can read the mailbox (via POP3 or IMAP for example) and parse the PARTNER and INVOICE messages. For each PARTNER message a work flow for a new account must be started. For each INVOICE message 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 with a period, such as .INVOICE. All tags are in UPPER CASE. An element may contain a value. The value might be only one line, in which 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 value MUST NOT contain a line which begins with a dot. All dates are represented as YYYYMMDD. All numbers are represented as 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 5.1. TAGS .PARTNER version Starts a partner message and indicates the version of the protocol. .ID email Identifies a partner. Partners are identified by unique e-mail addresses. .BUSINESSCODE Identifier of the company given by local authorities. In Finland this is the Y-tunnus. .NAME Name of the company. .ADDRESS Address of the company. Usually multiple lines. Format according to receiver's country. .EMAIL Contact e-mail if diferent from ID. .PHONE Contact phone. .IBAN Bank account in IBAN format. .ADRESSEE person Name of the person who should approve the partner account. .ENDPARTNER Ends a PARTNER message. 5.2. EXAMPLE .PARTNER 0.1 .ID juhani.jaakola@kolumbus.fi .BUSINESSCODE FI13727719 .NAME Dot Com Consulting .ADDRESS Solvikinkatu 11 B 28 00990 Helsinki Finland .EMAIL juhani.jaakola@kolumbus.fi .PHONE +358-40-5015182 .IBAN FI991234567890 .ADRESSEE Helena Takalo .ENDPARTNER 6. INVOICE MESSAGE 6.1. INVOICE HEADER .INVOICE version Starts the INVOICE message and indicates the version of the protocol. .ID number Unique identifier of the invoice - the invoice number. .PAYMENTCODE 1234567890 OPTIONAL code that is returned via bank when this invoice is paid. Viitenumero in Finland. .SENDER email Identifies the sending PARTNER. .RECEIVER email Identified the receiving PARTNER. .DATE yyyymmdd Date of the invoice. .DUEDATE yyyymmdd Due date. .CURRENCY ccc Three-character currency code. .ADRESSEE person Name of the person who should check or approve the invoice. .CUSTOMERREFERENCE text Customer's project number or any accounting information .TEXT Free text. .ENDINVOICE Ends the INVOICE message. 6.2. INVOICE ROW .ROW Starts a new row in the invoice. All amounts are in ROWs. .DESCRIPTION text One-line description of the item in this row. .COUNT ddd.dd OPTIONAL how many items in this row? .UNIT ccc OPTIONAL unit for .COUNT. .AMOUNT ddd.dd Amount without VAT. .DISCOUNT ddd.dd OPTIONAL Discount amount. .VATPERCENT ddd.dd VAT percent. .VAT ddd.dd VAT amount. .TOTAL ddd.dd Total to be paid for this row. .TEXT Free text. .ENDROW Ends a ROW. 6.3. EXAMPLE .INVOICE 0.1 .ID 123 .PAYMENTCODE 1234567890 .SENDER juhani.jaakola@kolumbus.fi .RECEIVER invoices@theotherfirm.com .DATE 20090419 .DUEDATE 20090503 .CURRENCY EUR .ADRESSEE Helena Takalo .CUSTOMERREFERENCE XYZ123 .ROW .DESCRIPTION Invoicing seminar after Easter .COUNT 1 .AMOUNT 500.00 .DISCOUNT 0.00 .VATPERCENT 22.00 .VAT 11.00 .TOTAL 511.00 .ENDROW .ROW .DESCRIPTION Train ticket a 33.60 .COUNT 2 .AMOUNT 67.20 .DISCOUNT 0.00 .VATPERCENT 22.00 .VAT 14.78 .TOTAL 81.98 .ENDROW .ENDINVOICE The total amount to be paid is 592.98, and it has to be paid on 3rd of May, 2009 to the account that belongs for "juhani.jaakola@kolumbus.fi". The actual account number was given by a preceding PARTNER message. 7. SECURITY CONSIDERATIONS This protocol is intended to replace paper invoices. Paper invoices do not provide for authentication nor encryption, so these features are not considered to be mandatory here. The main benefit of SINV is that invoices can be read automatically to receiver's systems - and this is so important that possible risks caused by missing authentication should not prevent using SINV. The mailbox used for receiving invoices should be read only by the program which parses SINV messages. This program MUST be built so that it can handle messages with syntax errors, such as SPAM, viruses and possible buffer overflow attacks. Authors' Addresses Juhani Jaakola Solvikinkatu 11 B 28 00990 Helsinki Finland Phone: +358-40-5015182 EMail: juhani.jaakola@kolumbus.fi