U.S. patent application number 13/974470 was filed with the patent office on 2013-12-26 for expense tracking, electronic ordering, invoice presentment, and payment system and method.
This patent application is currently assigned to Altisource Solutions S.a.r.l.. The applicant listed for this patent is Altisource Solutions S.a r.l.. Invention is credited to Sandra R. Blum, Russell G. Bulman.
Application Number | 20130346303 13/974470 |
Document ID | / |
Family ID | 41118516 |
Filed Date | 2013-12-26 |
United States Patent
Application |
20130346303 |
Kind Code |
A1 |
Bulman; Russell G. ; et
al. |
December 26, 2013 |
EXPENSE TRACKING, ELECTRONIC ORDERING, INVOICE PRESENTMENT, AND
PAYMENT SYSTEM AND METHOD
Abstract
Systems and methods are described for electronic invoice
presentment and payment processing. Requestors may place an order
to purchase goods or services from one or more vendors. Invoice
processing includes approval routing and dispute resolution.
Inventors: |
Bulman; Russell G.; (West
Palm Beach, FL) ; Blum; Sandra R.; (Lake Worth,
FL) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Altisource Solutions S.a r.l. |
Luxembourg |
|
LU |
|
|
Assignee: |
Altisource Solutions
S.a.r.l.
Luxembourg
LU
|
Family ID: |
41118516 |
Appl. No.: |
13/974470 |
Filed: |
August 23, 2013 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
13608747 |
Sep 10, 2012 |
8548877 |
|
|
13974470 |
|
|
|
|
12404958 |
Mar 16, 2009 |
8266028 |
|
|
13608747 |
|
|
|
|
12111794 |
Apr 29, 2008 |
8005730 |
|
|
12404958 |
|
|
|
|
10729019 |
Dec 8, 2003 |
7412418 |
|
|
12111794 |
|
|
|
|
60495103 |
Aug 15, 2003 |
|
|
|
60431438 |
Dec 6, 2002 |
|
|
|
61064605 |
Mar 14, 2008 |
|
|
|
Current U.S.
Class: |
705/40 |
Current CPC
Class: |
G06Q 30/0633 20130101;
G06Q 20/14 20130101; G06Q 30/06 20130101; G06Q 30/04 20130101; G06Q
30/0601 20130101; G06Q 20/102 20130101 |
Class at
Publication: |
705/40 |
International
Class: |
G06Q 20/10 20060101
G06Q020/10 |
Claims
1. A computer-implemented method of resolving a dispute associated
with an invoice, the computer comprising at least one processor,
the method comprising: providing, via the at least one processor, a
first interface for a vendor to upload an invoice; transmitting,
via the at least one processor, the invoice to a requester of an
item associated with the invoice for approval of the invoice;
transmitting, via the at least one processor, notification of the
invoice being rejected in response to a determination that the
requester rejects the invoice; providing, via the at least one
processor, a second interface for the vendor to view comments
entered by the requester indicating the reasons rejecting the
invoice, in response to a determination that the requester rejects
the invoice; and receiving, via the at least one processor,
comments from the vendor responding to the rejected invoice.
2. The computer-implemented method of claim 1, further comprising
providing, via the at least one processor, a third interface for a
vendor to submit a registration to use the first interface for the
vendor to upload an invoice.
3. The computer-implemented method of claim 2, further comprising
automatically transmitting, via the at least one processor,
information submitted during the registration to the first
interface for the vendor to upload an invoice.
4. The computer-implemented method of claim 1, wherein the second
interface for the vendor to view comments entered by the requester
indicating the reasons rejecting the invoice further comprises a
fourth interface for the vendor to resubmit the invoice to the
requester.
5. The computer-implemented method of claim 1, wherein receiving
the comments from the vendor responding to the rejected invoice
comprises receiving, via at least one processor, an electronic mail
message comprising the comments.
6. The computer-implemented method of claim 5, wherein the
electronic mail message further comprises a fifth interface for the
requestor to select to approve or reject the invoice.
7. The computer-implemented method of claim 6, wherein the vendor
receives a notification corresponding to the requestor's selection
to approve or reject the invoice.
8. A system for resolving a dispute associated with an invoice, the
system comprising: at least one processor; an invoice receiving
module for receiving, via the at least one processor, an invoice
from a vendor; an invoice transmitting module for transmitting, via
the at least one processor, the invoice to a requester of an item
associated with the invoice for approval of the invoice; an
approval module for processing with the at least one processor, the
invoice through an approval process based on at least one approval
rule defined by the requester; and a notification module for
transmitting, via the at least one processor, notification of the
invoice being rejected in response to a determination that the
invoice was rejected by the approval module.
9. The system of claim 8, further comprising an interface for the
vendor to view comments entered by the requester indicating the
reasons rejecting the invoice, in response to a determination that
the invoice was rejected by the approval module.
10. The system of claim 9, further comprising a comments module for
receiving, via the at least one processor, comments from the vendor
responding to the rejected invoice.
11. The system of claim 8, wherein the invoice is rejected by the
approval module in response to a determination that the requester
has manually rejected the invoice.
12. The system of claim 8, wherein the invoice is rejected by the
approval module in response to a determination that a total of the
invoice does not match a purchase order total indicated on a
purchase order associated with the invoice.
13. The system of claim 12, further comprising a payment module for
submitting, via the at least one processor, payment in response to
a determination that the approval module approved the invoice.
14. The system of claim 13, wherein the approval module comprises
an interface for the requester to accept or reject the invoice.
15. The system of claim 14, further comprising a data repository in
communication with the approval module and a dispute resolution
module, the dispute resolution module comprising an interface for
the requester to enter comments to the vendor associated with the
rejected invoice indicating the reasons for rejection, the comments
being stored in the data repository.
16. A computer-implemented method of resolving a dispute associated
with an invoice, the computer comprising at least one processor,
the method comprising: receiving, via the at least one processor,
an invoice from a vendor; processing, via the at least one
processor, the invoice through an approval and payment process;
transmitting, via the at least one processor, notification of the
invoice being rejected in response to a determination that a
requester of an item associated with the invoice rejects the
invoice; and receiving, via the at least one processor, comments
from the vendor responding to the rejected invoice.
17. The computer-implemented method of claim 16, further comprising
providing, via the at least one processor, an interface for the
vendor to view comments entered by the requester indicating the
reasons rejecting the invoice, in response to a determination that
the requester rejects the invoice.
18. The computer-implemented method of claim 17, further comprising
receiving a resubmitted invoice after a vendor views comments
entered by the requester indicating the reasons rejecting the
invoice.
19. The computer-implemented method of claim 18, further comprising
facilitating, via the at least one processor, payment in response
to a determination that the approval module approved the
resubmitted invoice.
20. The computer-implemented method of claim 19, further comprising
submitting, via the at least one processor, payment to the vendor
in response to the determination that the approval module approved
the resubmitted invoice.
Description
CLAIM OF PRIORITY
[0001] This application is a divisional of U.S. patent application
Ser. No. 13/608,747, entitled "Expense Tracking, Electronic
Ordering, Invoice Presentment, and Payment System and Method,"
filed Sep. 10, 2012, which is a continuation of U.S. patent
application Ser. No. 12/404,958, filed on Mar. 16, 2009, which
claims the benefit of U.S. Provisional Patent Application No.
61/064,605, filed on Mar. 14, 2008, and which is also a
continuation-in-part of U.S. patent application Ser. No.
12/111,794, filed on Apr. 29, 2008, now U.S. Pat. No. 8,005,730,
issued Aug. 23, 2011, which is a divisional of U.S. patent
application Ser. No. 10/729,019, filed on Dec. 8, 2003, now U.S.
Pat. No. 7,412,418, issued Aug. 12, 2008, and which claims the
benefit of U.S. Provisional Application No. 60/431,438, entitled
"Method and System for Expense Tracking," filed Dec. 6, 2002, and
U.S. Provisional Application No. 60/495,103 entitled "Electronic
Ordering, Invoice Presentment, and Payment System and Method,"
filed Aug. 15, 2003. The entire disclosures of the foregoing
applications are incorporated by reference herein.
BACKGROUND OF THE INVENTION
[0002] 1. Field of the Invention
[0003] The present invention relates to a method and system for
electronic ordering, invoice presentment, and payment.
[0004] 2. Background of the Technology
[0005] There exist in the art paper-based methods and systems for
payment of invoices, but these systems are typically slow and
costly for completing such transactions. Automatic payment approval
and presentment processes are also known, in which electronic
invoices are provided and approved, but these processes do not
include all functions necessary for completion of a transaction
(including, for example, payment). It is further known to provide
electronic payment approval and dispute resolution processes, but
without other necessary features for completion of a transaction,
such as a payment.
[0006] There remains an unmet need in the art to provide a wide
range of electronic budgeting, ordering, invoice presentment, and
payment functions within a single method and system, which are
useful, for example, for large organizations, such as mortgage
service companies. There is a further unmet need in the art for a
method and system that provides a wide range of such functions,
while at the same time providing enhanced customer assistance and
improved system integrity issues among interacting systems.
SUMMARY OF THE INVENTION
[0007] The following presents a simplified summary of one or more
aspects in order to provide a basic understanding of such aspects.
This summary is not an extensive overview of all contemplated
aspects, and is intended to neither identify key or critical
elements of all aspects nor delineate the scope of any or all
aspects. Its sole purpose is to present some concepts of one or
more aspects in a simplified form as a prelude to the more detailed
description that is presented later.
[0008] According to one aspect, an electronic invoice presentment
and payment system comprises a registration and order fulfillment
module for receiving orders from one or more requestors to purchase
goods or services from one or more vendors and an invoice
processing module for routing and approving invoices for orders
placed by the one or more vendors, wherein the invoice processing
module includes one or more custom invoice approval rules, the
invoice approval rules being customized for each of the one or more
requestors.
[0009] According to one aspect, a method for electronic invoice
processing via a computer, the computer comprising a process
comprises receiving a request from a requestor to purchase goods or
services from a vendor; generating, by the requestor, a purchase
order reflecting the requested purchase; generating, by the vendor,
an invoice for the requested purchase; generating, by the
requestor, a receiving report or approval of services rendered;
determining, via the processor and based on one or more
requestor-defined rules, whether the invoice can be approved; and
upon approval of the invoice, initiating an automated payment to
the vendor.
[0010] According to one aspect, a computer-implemented method of
resolving dispute associated with an invoice, the computer
comprising a data repository, comprise providing an interface for a
requestor to accept or reject an invoice; submitting the invoice
for payment if the requestor accepts the invoice, the invoice being
stored by the data repository; providing an interface for the
requestor to enter comments to the vendor indicating the reasons
for rejection if the invoice is rejected, the comments being stored
in the data repository; and providing an interface for the vendor
to respond to a rejected invoice or submit a new invoice, if the
invoice is rejected.
[0011] According to one aspect, a computer-implemented method of
evaluating an invoice for approval, the computer comprising a
processor, comprises receiving an invoice; determining, via the
processor, whether the invoice total matches the purchase order
total indicated on a purchase order associated with the invoice;
and if the invoice total does not match the purchase order total,
determining, via the processor and based on one or more
requestor-defined rules, whether to approve the invoice.
[0012] According to one aspect, a system for invoice processing
comprises a processor, a user interface for functioning via the
processor, and a repository accessible by the repository, wherein a
request is received from a requestor to purchase goods or service
from a vendor, a purchase order reflecting the requested purchase
is generated by the requestor, an invoice for the requested
purchase is generated by the vendor, the processor determines based
on one or more requestor defined rules, whether the invoice can be
approved, and upon approval of the invoice, automatic payment to
the vendor is initiated.
[0013] According to one aspect, a computer program product
comprising computer usable medium having control logic stored
therein causing a computer to process an invoice, the control logic
comprises first computer readable program code means to generate a
request from a requestor to purchase goods or services from a
vendor, second computer readable program code means to generate a
purchase order reflecting the requested purchase, third computer
readable program code means to generate a receiving report or
approval for services rendered reflecting the receipt of the
requested purchase; fourth computer readable program code means to
generate an invoice for the requested purchase, fifth computer
readable program code means to determine, based on one or more
requestor-defined rules, whether the invoice can be approved, and
sixth computer-readable program code means to initiate automatic
payment to the vendor upon approval of the invoice.
[0014] To the accomplishment of the foregoing and related ends, the
one or more aspects comprise the features hereinafter fully
described and particularly pointed out in the claims. The following
description and the annexed drawings set forth in detail certain
illustrative features of the one or more aspects. These features
are indicative, however, of but a few of the various ways in which
the principles of various aspects may be employed, and this
description is intended to include all such aspects and their
equivalents.
BRIEF SUMMARY OF THE DRAWINGS
[0015] FIG. 1 depicts an exemplary system diagram of various
hardware components and other features in accordance with aspects
of the present invention.
[0016] FIG. 2 depicts a high-level block diagram of an EIPP system,
in accordance with some aspects of the invention.
[0017] FIG. 3 depicts a registration and order fulfillment module,
in accordance with some aspects of the invention.
[0018] FIG. 4 is a flowchart depicting a client rules approval
process, in accordance with some aspects of the invention.
[0019] FIG. 5 depicts an exemplary approval routing screen,
according to some aspects of the invention.
[0020] FIG. 6 is a flowchart depicting a dispute resolution
process, in accordance with some aspects of the invention.
[0021] FIGS. 7A 7C are exemplary screen shots depicting various
aspects of dispute resolution, in accordance with some aspects of
the invention.
[0022] FIGS. 8 and 9 are exemplary screen shots, in accordance with
some aspects of the invention.
[0023] FIG. 10 depicts a computer system for implementing various
aspects of the present invention.
DETAILED DESCRIPTION
[0024] An electronic invoice presentment and payment (EIPP) system
and method are described herein. The EIPP system and method brings
the entire invoicing process, from presentment to payment, online
using web-based technologies, platforms, and transports.
[0025] FIG. 1 depicts an exemplary system diagram 100 of various
hardware components and other features in accordance with aspects
of the present invention. As depicted in FIG. 1, one or more
vendors 110 and requestors 120 may be communicatively coupled to an
EIPP server 130 over network 116. Vendors 110 and requestors 120
may access EIPP server 130 via terminals 112 and 122, respectively,
which may be a personal computer (PC), microcomputer, mainframe
computer, telephone device, PDA, or any other device having a
processor and input capability. EIPP server 130 may be a personal
computer (PC), microcomputer, mainframe computer or any other
device having a processor and repository for data or can interface
to a repository for maintained data.
[0026] According to some aspects of the invention, requestors may
be, for example, real estate owners or other property holders such
as a corporation, bank, or other entity having real estate owned
properties. The requestors may order one or more services from
vendors in connections with the sale or management of a property,
or any other transactions.
[0027] EIPP server 130 may comprise a plurality of modules forming
an integrated invoice management platform. FIG. 2 depicts a
high-level block diagram of an EIPP system 130, in accordance with
some aspects of the invention. EIPP system 130 may include a
registration and order fulfillment module 210, an invoice
processing module 220, and a data handling module 230.
[0028] Registration and order fulfillment module 210 may provide
for various functions, such as, for example, online vendor
registration, submission and review of purchase orders, and
creation of receive reports. Invoice processing module 220 may
provide tools for approving and routing invoices and for electronic
dispute resolution. Data handling module 230 may be configured to
format data to be exchanged into various file formats, and to
perform validation on file transfer between systems.
[0029] FIG. 3 depicts registration and order fulfillment module 210
in greater detail. Registration and order fulfillment module 210
may include a registration sub-module 302, a purchase order
processing sub-module 304, and a receive reports sub-module
306.
[0030] Registration sub-module 302 may provide one or more
interfaces, enabling vendors and/or requestors to register to use
the EIPP system. Vendor registration may include providing details
of the vendor's business such as, for example, the business name,
address, phone number, email address, services provided, price
list, and/or other vendor information. The vendor may also be
required to provide banking information which may be used to remit
payments from the requestors. According to some aspects, upon
completion of vendor registration, the vendor's information is
automatically uploaded to an accounts payable system associated
with the requestor(s) to ensure smooth payment processing.
[0031] Registration sub-module 302 may also provide interfaces
enabling requestors to register. Like vendors, requestors may be
required to provide business information, such as business name,
address, phone number, and email address. The vendors may also be
required to submit banking and/or credit card information for
processing payments.
[0032] Purchase order processing sub-module 304 may be provided for
generating electronic purchase orders. When a requestor wishes to
order products and/or services from a vendor, purchase order
processing sub-module 304 may generate an electronic purchase order
which is transmitted to the vendor.
[0033] Receive reports may be used to track items received and
accepted by a requestor. As such, receive reports sub-module 306
may be configured to log orders received and accepted, and to
generate a report. Similarly, in the case of services, receive
reports sub-module 306 may be configured to log a requestor's
approval of services rendered. The receive reports may be used to
validate invoices. For example, if a requestor orders 100
air-conditioners from a vendor and receives 78 units, a receive
report is generated indicating that 78 units were delivered. If the
requestor accepts the 78 units, the report also indicates that the
78 units were accepted.
[0034] Referring again to FIG. 2, invoice processing module 220 may
provide tools for processing invoices including, for example, tools
for approving invoices and for routing invoices to the appropriate
parties for approval as needed. Some invoices may be approved
automatically while others may require approval by one or more
approvers designated by the requestor. According to some aspects of
the invention, invoice processing module 220 may be used in
conjunction with client-defined rules to evaluate an invoice for
automatic approval.
[0035] Client-defined rules may include rules that define whether
an invoice may be automatically approved based on the quantity of
goods delivered, the invoice price, delivery dates, and/or other
factors. For example, a client may configure rules indicating that
a delivery date cannot exceed a predetermined amount of days after
the expected received date indicated on the order report. As other
examples, a client may configure rules indicating that an invoice
price can or cannot exceed the order price, or that a quantity of
goods received can or cannot exceed an amount ordered.
[0036] To determine whether an invoice can be approved
automatically based on user configured rules such as the examples
described above, a rules engine may be provided as a configurable
set of database tables that establish relationships, comparisons,
and resulting actions amongst invoice, order, and receiving report
data attributes. FIG. 4 is a flowchart depicting a client rules
approval process. As depicted in FIG. 4, the rules engine may use a
three-way mapping of the receive report, the purchase order, and
the invoice to determine whether an invoice may be approved. The
purchase order indicates the goods and/or services initially
requested by the requestor. The receive report indicates that the
requestor has accepted or approved the delivered goods or services,
and the invoice represents the goods and/or services billed by the
client. Accordingly, the rules engine may validate an invoice by
comparing the values of all three reports.
[0037] As depicted at 402, the process begins when a vendor submits
an invoice. As depicted at 404, the invoice validation and approval
sub-module may determine whether the invoice total amount is equal
to, greater than, or less than the total amount quoted on the
confirmed purchase order. As depicted at 406, the invoice
validation and approval sub-module may also determine whether the
amount charged for each invoice item is equal to, less than, or
greater than the per item amount quoted on the purchase order. The
inquiries depicted at 404 and 406 are evaluated using purchase
order rules 408.
[0038] The price details on the invoice received may be compared to
the details on the purchase order. For example, the cumulative
invoice total may be compared to the purchase order total.
Likewise, the price for each item on the invoice may be compared to
the price for each item on the purchase order. Purchase order rules
408, which are pre-configured by the client/requestor, indicate
whether the invoice should be approved.
[0039] As depicted at 410, it is determined whether the amount of
goods delivered is equal to, less than, or greater than the amount
of goods received. That is, the amount of items delivered on the
invoice is compared to the amount of items delivered and received.
As depicted at 412, the invoice date of service may be compared to
the purchase order delivery date. This includes a comparison of the
service delivery date against the service order delivery data
specified on the purchase order. As the inquiries performed at
steps 410 and 412 include evaluating invoices in light of both a
purchase order and a receive report, the inquiries are processed by
purchase order rules 408 and receipt rule 414. Like the purchase
order rules, receipt rules may be preconfigured by the
client/requestor.
[0040] Invoices that cannot be automatically approved may require
approval by one or more designated approvers. FIG. 5 depicts an
example of an approval routing screen 502. As depicted, the
approval routing form indicates the invoice number as well as the
date and time the invoice was created. The invoice approval form
may also include reasons why approval is needed. For example,
approval may be needed because the cost of the invoice exceeds a
predefined threshold. The approver may select from buttons or other
selection mechanisms to approve the invoice or reject the invoice.
The user may also include approval comments by selecting the
appropriate button. According to some aspects of the invention,
multiple parties may be required to approve an invoice. As such,
the invoice approval screen may display the entire approval
routing, including the order of the current reviewer within the
overall process. If the invoice is rejected, the vendor may be sent
an email or other indication of such rejection and, e.g., a link to
the EIPP system to obtain further details.
[0041] Invoice processing module 220 may also provide tools for
online dispute resolution. Online dispute resolution enables a
vendor to view comments associated with rejected invoices, and
respond to the rejection or resubmit the invoice. FIG. 6 is a
flowchart depicting a dispute resolution process, in accordance
with some aspects of the invention. As depicted at 602, a requestor
may receive an invoice detailing the products ordered and
delivered, as well as the cost. Upon reviewing the invoice, the
requestor may determine whether or not to approve the invoice, as
depicted at 604. If the invoice is approved, it is paid, as
depicted at 606.
[0042] However, if the invoice is not approved, the requestor may
enter comments into the EIPP system detailing the reasons for the
rejection, as depicted at 608. The vendor may then be notified by
email or other means of the rejection, as depicted at 610. The
notification may include the order number and invoice number
associated with the rejected invoice. The notification may further
include, e.g., a link to the submitted invoice.
[0043] Upon receipt of notification that an invoice has been
rejected and upon selection of the link to access the invoice, the
vendor may decide to respond to the rejection, or to resubmit the
invoice, as depicted at 612. If the vendor decides to resubmit, the
vendor may generate a new invoice and forward it to the requestor,
as depicted at 614. However, if the vendor chooses to respond
rather than resubmit, a response may be send via email or other
means to the requestor, as depicted at 616. The vendor may provide
comments indicating why the invoice should be approved.
[0044] As depicted at 618, the requestor may then receive an email
or other notification that the vendor has responded to the
rejection of the invoice. According to some aspects, the
notification may provide options for approving or rejecting the
invoice again right from the email. For example, the email message
may include an approve button and a reject button, each of which,
when selected, would transmit the appropriate message to the
vendor. In other aspects, the email message may contain a link to
the EIPP system where the requestor can review the vendor's
comments and decide whether to approve the invoice or reject it
again. As depicted at 620, the requestor determines whether to
approve or reject the invoice.
[0045] If the requestor again rejects the invoice, a "final message
may be sent to the vendor indicating the rejection, as depicted at
622. The message may include details about the final rejection, and
instructions to submit a new invoice. According to some aspects,
the new invoice may be created directly from the email or other
message. In other aspects, the vendor may be directed to log into
the EIPP system to create a new invoice. If the requestor chooses
to approve the invoice, as depicted at 624, the invoice is
paid.
[0046] FIGS. 7A-7C depict various screenshots, graphical user
interface screens, and message windows which may be presented
during a dispute resolution process, according to some aspects of
the invention. As depicted in FIG. 7A, a Submitted invoice Details
window displays the status of a pending invoice. For example,
invoice number CBTrashOut, depicted in FIG. 7A, has been rejected.
A vendor reviewing this screen has the option to submit a response
or to create a new invoice, as depicted at 702 and 704,
respectively. The user may also view comments associated with the
rejection, by selecting the link depicted at 706.
[0047] FIG. 7B is an example of an Invoice Comments Interface. This
interface may be provided to a requestor after a vendor has entered
comments regarding an initial rejection of an invoice. The
requestor may then approve, reject, or respond to the requestor.
FIG. 7C depicts an example final rejection email which may be
provided to a vendor after an invoice has been twice rejected. In
this example, the requestor's only option is to create a new
invoice.
[0048] According to some aspects of the invention, an EIPP system
may interact with and exchange data with a plurality of sources. As
such, data handling module 230 may enable the EIPP system to
transmit data in a variety of file formats. For example, the EIPP
system may be configured to support fixed flat files, pipe
delivered files, comma separated files, Excel.TM. files, XML files,
and/or other file types.
[0049] Moreover, to avoid problems associated with missing data
transfer, data handling module 230 may be configured to log errors
occurring during a transfer process. Upon logging an error, a
system administrator may be notified of the location of the error
log. Any transaction associated with the error may be
re-transmitted after the error has been researched and corrected.
According to some aspects of the invention, a report may be
generated when data is successfully sent and confirmation has been
received.
[0050] According to some aspects of the invention, approved
invoices may be interfaced with a requestor's accounts payable
system. Invoices may be paid directly via direct deposit to the
vendor's bank account after an invoice has been approved. The
vendor may be notified of the payment, for example, via email.
Other notification methods, such as facsimile may also be used.
Vendors may also view their invoices and payment status by logging
into the EIPP interface.
[0051] FIG. 8 is a screen shot of an EIPP work area. The work area
may present a list of all invoices, and indicate the status of the
invoice. Invoices may be worked on by multiple users. Selecting an
invoice may bring up the invoice details, as depicted in FIG.
9.
[0052] The present invention may be implemented using a combination
of hardware, software and firmware in a computer system. In an
aspect of the present invention, the invention is directed toward
one or more computer systems capable of carrying out the
functionality described herein. An example of such a computer
system 1000 is shown in FIG. 10.
[0053] Computer system 1000 includes one or more processors, such
as processor 1004. The processor 1004 is connected to a
communication infrastructure 1006 (e.g., a communications bus,
cross-over bar, or network). Various software aspects are described
in terms of this exemplary computer system. After reading this
description, it will become apparent to a person skilled in the
relevant art(s) how to implement the invention using other computer
systems and/or architectures.
[0054] Computer system 1000 can include a display interface 1002
that forwards graphics, text, and other data from the communication
infrastructure 1006 (or from a frame buffer not shown) for display
on a display unit 1030. Computer system 1000 also includes a main
memory 1008, preferably random access memory (RAM), and may also
include a secondary memory 1010. The secondary memory 1010 may
include, for example, a hard disk drive 1012 and/or a removable
storage drive 1014, representing a floppy disk drive, a magnetic
tape drive, an optical disk drive, etc. The removable storage drive
1014 reads from and/or writes to a removable storage unit 1018 in a
well-known manner. Removable storage unit 1018, represents a floppy
disk, magnetic tape, optical disk, etc., which is read by and
written to removable storage drive 1014. As will be appreciated,
the removable storage unit 1018 includes a computer usable storage
medium having stored therein computer software and/or data.
[0055] Alternative aspects of the present invention may include
secondary memory 1010 and may include other similar devices for
allowing computer programs or other instructions to be loaded into
computer system 1000. Such devices may include, for example, a
removable storage unit 1022 and an interface 1020. Examples of such
may include a program cartridge and cartridge interface (such as
that found in video game devices), a removable memory chip (such as
an erasable programmable read only memory (EPROM), or programmable
read only memory (PROM) and associated socket, and other removable
storage units 1022 and interfaces 1020, which allow software and
data to be transferred from the removable storage unit 1022 to
computer system 1000.
[0056] Computer system 1000 may also include a communications
interface 1024. Communications interface 1024 allows software and
data to be transferred between computer system 1000 and external
devices. Examples of communications interface 1024 may include a
modem, a network interface (such as an Ethernet card), a
communications port, a Personal Computer Memory Card International
Association (PCMCIA) slot and card, etc. Software and data
transferred via communications interface 1024 are in the form of
signals 1028, which may be electronic, electromagnetic, optical or
other signals capable of being received by communications interface
1024. These signals 1028 are provided to communications interface
1024 via a communications path (e.g., channel) 1026. This path 1026
carries signals 1028 and may be implemented using wire or cable,
fiber optics, a telephone line, a cellular link, a radio frequency
(RF) link and/or other communications channels. In this document,
the terms "computer program medium" and "computer usable medium"
are used to refer generally to media such as a removable storage
drive 1080, a hard disk installed in hard disk drive 1070, and
signals 1028. These computer program products provide software to
the computer system 1000. The invention is directed to such
computer program products.
[0057] Computer programs (also referred to as computer control
logic) are stored in main memory 1008 and/or secondary memory 1010.
Computer programs may also be received via communications interface
1024. Such computer programs, when executed, enable the computer
system 1000 to perform the features of the present invention, as
discussed herein. In particular, the computer programs, when
executed, enable the processor 1010 to perform the features of the
present invention. Accordingly, such computer programs represent
controllers of the computer system 1000.
[0058] In an aspect of the present invention where the invention is
implemented using software, the software may be stored in a
computer program product and loaded into computer system 1000 using
removable storage drive 1014, hard drive 1012, or communications
interface 1020. The control logic (software), when executed by the
processor 1004, causes the processor 1004 to perform the functions
of the invention as described herein. In another aspect of the
present invention, the invention is implemented primarily in
hardware using, for example, hardware components, such as
application specific integrated circuits (ASICs). Implementation of
the hardware state machine so as to perform the functions described
herein will be apparent to persons skilled in the relevant
art(s).
[0059] While the foregoing disclosure discusses illustrative
aspects and/or embodiments, it should be noted that various changes
and modifications could be made herein without departing from the
scope of the described aspects and/or embodiments as defined by the
appended claims. Furthermore, although elements of the described
aspects and/or embodiments may be described or claimed in the
singular, the plural is contemplated unless limitation to the
singular is explicitly stated. Additionally, all or a portion of
any aspect and/or embodiment may be utilized with all or a portion
of any other aspect and/or embodiment, unless stated otherwise.
* * * * *