Darko,
Below are a few comments that add some "best
practices" comments that complement the helpful implementation suggestions
that Stephen Green and Ken Holman offered. UBL probably has a place for
everything (or can be suitably adapted), but it is important to consider the
advantages of keeping things simple. From a TQM (total quality management)
perspective, it is far better to prevent invoice adjustments than to devise
means of doing adjustments although certainly adjustments are needed.
One of the preventative measures is when shifting from non-electronic
to electronic invoicing, the buyer and seller parties (and tax auditors) are
best served by making transactions as atomistic as possible, with one physical
transaction generating a corresponding, specific electronic invoice. In
electronic invoicing, the invoice transaction has to satisfy the process and
data needs of at least three diverse sets of systems, the seller's, the buyer's
and the governmental tax authorities', along with any intermediary or
outsourced systems, with the objective of end-to-end automation of all
system-to-system handoffs.
Aggregated invoice transactions greatly increase the likelihood
and significance of process breakdown, with the need for replacement invoices
or credit notes being symptoms of process breakdown. In some manual invoicing
situations, the buyer and seller might have agreed on, for example, processing
only one aggregate invoice per month for a series of transactions, because
manually processing small-value invoices costs a substantial amount of money. On
the other hand, processing individual invoices electronically is much less
costly, if no human intervention is needed (e.g., the invoice uploads without
error into the buyer's ERP or inventory system). If the seller's sales order to
cash cycle and the buyer's order to electronic payment cycle become more
"atomistic" a lot of complexity and risk of kickouts are eliminated
and those that remain are smaller and less complex to diagnose.
Although the various European tax authorities do not require
"atomistic" invoices, satisfying their stated requirements is much
easier if the transaction being invoiced is atomistic. (Below are two links,
one to a
http://www.hmrc.gov.uk/vat/managing/special-situations/returned-goods.htm
1.
an Invoice represents a claim for payment for specific goods
and
services or for the provision of goods and services over a
defined
period of time
2.
a Credit Note must refer to an original Invoice
3.
reference to a contract or framework agreement may only be
made
at document level
4.
Payment Means and Terms stated at document level must
apply
to all Invoice or Credit Note Lines
5.
accounting details stated at document level must apply to all
Invoice
or Credit Note Lines
6.
tax information stated at document level must apply to all
Invoice
or Credit Note Lines
7.
periodic Invoices including returns may result in a negative
total
8.
stated pre-payments must apply to the Invoice as a whole
9. Invoice acceptance applies to the
entire Invoice
Your query regarding "point of processing" is a
subset of buy-side workflow that, I suggest, is better addressed by providing
the payment processor (whether internal or outsourced) with either access to
upstream transactions (the electronic purchase orders that spawned the electronic
invoice transactions) or to persistent master data (e.g., how to route invoices
charged to a given cost center – which might only coincidentally be the
same as "point of processing").
As is the case for tax accounting compliance, implementing buyside
approval workflow becomes much simpler if the invoice transactions are
atomistic, because it then becomes less likely that multiple and perhaps
diverse routing steps are required.
Colts
Neck Solutions LLC
From: Darko Gulija
[mailto:Darko.Gulija@infodom.hr]
Sent: Monday, July 13, 2009 8:37
AM
To: ubl-dev@lists.oasis-open.org
Cc: Hrvoje Ljubicic; Ivan
Magdalenic; Ranko Smokvina
Subject: [ubl-dev] Mapping
business model fields to UBL 2.0
Dear
all,
I'm
a member of a committee that works on a Croatian standard for e-Invoice
based on UBL.
We studied UBL version 2.0 as a base, but found out that we had a few fields in
our business model for which we could not find a proper mapping.
Here
they are:
1.
InvoiceReference
Invoice
could contain a reference to another invoice, most often expressed through the
invoiceID and date. This information is most often used in DebitNote or
CreditNote.
Example
of business context is when supplier sends a CreditNote document to the buyer
because on one of the previous invoices there was an error and the price was
higher than it should have been. Now, when supplier wants to issue the document
to give buyer a credit for the difference, there should be a reference to the
original document (invoice) that contained the error.
2.
OfferReference
Invoice
could contain reference to the offer that started the whole transaction
3.
BusinesEventOrActivityIndicator
Invoice
(especially Debit Note and Credit Note) could contain the codes and
corresponding explanations of the business events that resulted in issuing the
invoice.
Example
of business context is that ,e.g. a Credit Note is usually a result of
wrongly calculated price on one of previous invoices, but there could also be
another reasons for issuing it. It is sometimes important to exactly know the
reason why it has been issued (expressed through the code of the type of
business transaction that cause it and corresponding explanation), so that it
could trigger the specific action on the recipient side.
4.
PlaceOfProcessing
Part
of the enterprise responsible for processing of e-invoice (usually address or
ID of regional headquarter – potentially expressed as GLN).
In
some enterprises there are rules where the paper invoices should be sent
to (to which address - usually regional headquarters), so that regional
headquarter office could check whether the prices and the quantities match with
the supplied goods and approve (or disapprove) its further processing.
When
converting to e-invoicing, this information is still required because the
business rules within the company that decide who should give approval for the
invoice are still in place (and they are based on that address – business
processes and internal ERP systems are still set up for processing paper
invoices and they need this information, although the address of the “inbox”
will be the same for all the e-invoices).
I’d
appreciate if you could help us to find out the best solution for the problems
mentioned above, as we would like to avoid treating them as extensions if
possible.
Best
regards,
Darko
Gulija
Knowledge Management
Consultant
Infodom
d.o.o.
A. ®aje 61/1
10000 Zagreb, Croatia
T: +385 1 3090 507
F: +385 1 3040 593