U.S. patent application number 09/974551 was filed with the patent office on 2003-04-10 for method and system for tracking and verifying billing exceptions.
Invention is credited to DeWitt, Richard R., Lannie, Nadia Hermiz.
Application Number | 20030069845 09/974551 |
Document ID | / |
Family ID | 25522168 |
Filed Date | 2003-04-10 |
United States Patent
Application |
20030069845 |
Kind Code |
A1 |
DeWitt, Richard R. ; et
al. |
April 10, 2003 |
Method and system for tracking and verifying billing exceptions
Abstract
A method and system for verifying charges billed to a customer
by a vendor is disclosed. A set of billing data associated with the
charges is loaded into a billing verification system that is
accessible by both the customer and the vendor via a distributed
computer network. The customer reviews the billing data via the
billing verification system to identify billing exceptions
associated with any disputed charges. A billing exception record is
generated in the billing verification system for each of the
billing exceptions. The vendor is then notified of the billing
exceptions. The vendor reviews and responds to the billing
exception records via the billing verification system. A billing
exception response record is generated for each vendor response.
The customer is then notified of the reviewed billing exception
response records.
Inventors: |
DeWitt, Richard R.;
(Kenosha, WI) ; Lannie, Nadia Hermiz; (Chicago,
IL) |
Correspondence
Address: |
BRINKS HOFER GILSON & LIONE
P.O. BOX 10395
CHICAGO
IL
60610
US
|
Family ID: |
25522168 |
Appl. No.: |
09/974551 |
Filed: |
October 9, 2001 |
Current U.S.
Class: |
705/40 |
Current CPC
Class: |
G06Q 40/00 20130101;
G06Q 20/102 20130101; G06Q 20/105 20130101; G06Q 20/108 20130101;
G06Q 30/04 20130101 |
Class at
Publication: |
705/40 |
International
Class: |
G06F 017/60 |
Claims
1. A method of verifying charges billed to a customer by a vendor,
comprising: loading a set of billing data associated with the
charges into a billing verification system that is accessible by
both the customer and the vendor via a distributed computer
network; facilitating customer review of the billing data via the
billing verification system to identify one or more billing
exceptions associated with one or more disputed charges; generating
a billing exception record in the billing verification system for
each of the billing exceptions; notifying the vendor of the
availability of the billing exception records; facilitating vendor
review of and response to the billing exception records via the
billing verification system; generating a billing exception
response record for each of the vendor responses; and notifying the
customer of the availability of the vendor response records.
2. A method of verifying vendor charges billed to a customer by a
vendor as in claim 1, wherein: the vendor provides the set of
billing data in the form of an electronic data file; and the set of
billing data is loaded into the billing verification system from
the electronic data file.
3. A method of verifying vendor charges billed to a customer by a
vendor as in claim 1, wherein: the vendor provides the set of
billing data in the form of a hardcopy bill; and the set of billing
data is loaded into the billing verification system by an operator
that manually enters the billing data from the hardcopy bill.
4. A method of verifying vendor charges billed to a customer by a
vendor as in claim 1, wherein the set of billing data represents
one or more invoices from the vendor.
5. A method of verifying vendor charges billed to a customer by a
vendor as in claim 5, wherein the disputed charges consist of one
or more line items selected from the vendor invoices.
6. A method of verifying vendor charges billed to a customer by a
vendor as in claim 5, wherein the disputed charges consist of all
line items selected from one or more of the vendor invoices.
7. A method of verifying vendor charges billed to a customer by a
vendor as in claim 1, wherein each of the vendor responses
corresponds to an action selected from the group consisting of:
allowing the billing exception; disallowing the billing exception;
and partially allowing the billing exception.
8. A method of verifying vendor charges billed to a customer by a
vendor as in claim 7, wherein the partial allowance of the billing
exception includes identifying a partially allowed dollar
value.
9. A method of verifying vendor charges billed to a customer by a
vendor as in claim 1, further comprising: incorporating customer
comments in the billing exception record.
10. A method of verifying vendor charges billed to a customer by a
vendor as in claim 1, further comprising: attaching customer
supporting electronic documentation to the billing exception
record.
11. A method of verifying vendor charges billed to a customer by a
vendor as in claim 1, further comprising: incorporating vendor
comments in the billing exception response record.
12. A method of verifying vendor charges billed to a customer by a
vendor as in claim 1, further comprising: attaching vendor
supporting electronic documentation to the billing exception
response record.
13. A method of verifying vendor charges billed to a customer by a
vendor as in claim 1, further comprising: automatically generating
a credit for an allowed billing exception dollar value against a
vendor account in a customer accounts payable system.
14. A method of verifying repair facility charges billed to an
equipment owner by a repair agent, comprising: loading a set of
repair billing data associated with the repair charges into a
computer-based billing verification system that is accessible to
both the equipment owner and the repair agent via a distributed
computer network; facilitating equipment owner review of the repair
billing data via the billing verification system to identify one or
more billing exceptions associated with one or more disputed repair
charges; generating a billing exception record in the billing
verification system for each of the billing exceptions; notifying
the repair agent of the billing exceptions; facilitating repair
agent review of and response to the billing exception records via
the billing verifications system; generating a billing exception
response record for one or more repair agent responses; and
notifying the customer of the repair agent responses.
15. A method of verifying repair charges billed to an equipment
owner by a repair agent as in claim 14, wherein facilitating repair
agent review further comprises facilitating review by a repair
agent managing representative of all billing exception records.
16. A method of verifying repair charges billed to an equipment
owner by a repair agent as in claim 14, wherein facilitating repair
agent review further comprises facilitating review by a repair
agent field representative of only those billing exception records
that are associated with a field repair facility for which the
field representative is responsible.
17. A method of verifying repair charges billed to an equipment
owner by a repair agent as in claim 14, wherein the billing
exception records are displayed in a format that complies with the
Association of American Railroads Interchange Rules governing
billing repair cards.
18. A system for verifying vendor charges billed to a customer,
comprising: a billing verification database; means for loading a
set of billing data associated with the charges into the database;
a customer graphical user interface in communication with the
database and operable to facilitate customer review of the billing
data to identify a plurality of billing exceptions associated with
a plurality of disputed charges and to generate a billing exception
record in the database for each of the billing exceptions; a vendor
graphical user interface in communication with the database and
operable to facilitate vendor review of the billing exception
records to generate a billing exception response record in the
database for each of the reviewed billing exception records.
19. A system for verifying vendor charges billed to a customer as
in claim 18, wherein each billing exception response record is
contained within the corresponding billing exception record.
20. A system for verifying vendor charges billed to a customer as
in claim 18, further comprising: a server in communication with the
billing verification database, and operable to generate a plurality
of custom web pages; and wherein the customer graphical user
interface and the vendor graphical user interface each include at
least one of the plurality of custom web pages generated by the
server.
21. A system for verifying vendor charges billed to a customer as
in claim 20, wherein the customer graphical user interface is
displayed on a customer computer workstation that is in
communication with the server via a distributed computer
network.
22. A system for verifying vendor charges billed to a customer as
in claim 20, wherein the vendor graphical user interface is
displayed on a vendor computer workstation that is in communication
with the server via a distributed computer network.
23. A system for verifying vendor charges billed to a customer as
in claim 18, further comprising: a mainframe accounting system
operable to store the set of billing data; and wherein the means
for loading the set of billing data transfer the set of billing
data from the mainframe accounting system to the billing
verification database.
24. A system for verifying vendor charges billed to a customer as
in claim 18, wherein the server is in communication with a customer
accounts payable system.
Description
BACKGROUND OF THE INVENTION
[0001] The present invention relates to billing exceptions. In
particular, this invention relates to methods and systems for
verifying charges billed by a vendor to a customer and for
processing the customer's exceptions to those charges. Although it
is applicable to a wide variety of industries, the invention will
be described with a particular emphasis on billing for railcar
repair services in the railroad industry.
[0002] The railroad network in the United States includes a number
of railroad systems that are owned by different companies.
Together, these systems comprise a complete railroad network that
connects locations across the nation. Although some railroad
companies also own their own railcars, many railcars are owned by
other companies that do not own any part of the railroad network
itself. To move from one location to another, therefore, one
company's railcars frequently need to travel over another company's
railroad system.
[0003] Repair facilities are positioned at various locations
throughout the railroad network. These facilities are available to
perform any necessary repairs to railcars in the area. The repair
facilities are owned and operated by various railroad companies and
independent repair contractors. When a railcar repair becomes
necessary, it typically is performed at the nearest repair
facility. Under limited authority granted by the Association of
American Railroads (AAR) Interchange Rules, the owner of the repair
facility acts as a repair agent for the owner of the railcar
needing repair. In this way, the owner of a given repair facility
may act as a repair agent for a number of different railcar owners.
Likewise, a given owner's railcars may be repaired by a number of
different repair agents as those railcars travel the railroad
network. In these situations, the repair agent is a vendor of
services provided to its customer, the railcar owner.
[0004] Like many other types of vendors, repair agents typically
bill railcar owners for repair services on a monthly basis. Billing
for railcar repairs is generally governed by the AAR Interchange
Rules. A typical monthly bill may include charges for all repairs
performed on the owner's railcars at all of the repair agent's
facilities. A billing repair card is included for each repair. Each
billing repair card indicates, among other things, the date of
repair, the railcar number, the type of car, the repair location,
and a description and cost of the repair, including parts and
labor. If not governed directly by the AAR Interchange Rules, the
cost of repair may be governed by one or more repair agreements
between the repair agent and the railcar owner.
[0005] In some instances, a railcar owner may wish to dispute
charges billed by a repair agent. For example, the repair agent may
have charged the wrong railcar owner, charged more than is allowed
by the applicable repair agreement, or failed to justify the charge
for a given repair. These situations also are governed by the AAR
Interchange Rules. In these cases, the railcar owner generates an
"exception" to the repair bill, explaining the reasons for
disputing the particular repair charges. According to existing
practices, the railcar owner prepares an exception packet, which
includes an exception letter, copies of the billing repair cards
for which exceptions are taken, and any necessary supporting
documentation. The railcar owner indicates the reasons for the
exceptions on the billing repair cards. The owner sends the entire
exception packet to the repair agent. The repair agent reviews the
exception packet and approves or disapproves each exception. For
each exception approved or accepted by the repair agent, the
appropriate repair charges are credited to the railcar owner's
account or counter-billed bto the repair agent by the railcar
owner. In some cases, the repair agent may approve only a portion
of an exception, in which case only a portion of the repair charges
are credited.
[0006] The existing system for processing exceptions is inefficient
and paper-intensive. The railcar owner must wait to receive an
exception approval from the repair agent before its account is
credited. The repair agent, however, must investigate the repair to
which an exception is taken to determine whether the charges are
appropriate. In many cases, a manager of the repair agent separates
the billing repair cards according to the facility that performed
the repairs. The manager then distributes the billing repair cards
to field representatives at the various repair facilities for their
comments. Once the manager receives comments from all of the field
representatives, the manager makes a final decision to approve,
disapprove, or partially approve each exception. The manager then
sends these responses to the railcar owner. This process typically
requires months to complete. Moreover, the shipping and handling
associated with all of this correspondence is expensive for both
the repair agent and the railcar owner. Accordingly, there is a
need for a more efficient and less expensive method and system for
tracking and processing billing exceptions.
[0007] It is, therefore, an object of the present invention to
provide an improved method and system for efficiently tracking and
verifying charges billed to a customer by a vendor. It is another
object of the present invention to provide an improved method and
system for efficiently tracking and verifying charges billed by a
repair agent to an equipment owner, preferably in a manner that
complies with the AAR Interchange Rules.
BRIEF SUMMARY OF THE PREFERRED EMBODIMENTS
[0008] In accordance with the present invention, a method and
system are described for verifying charges billed to a customer by
a vendor.
[0009] According to one aspect of the present invention, there is
provided a method of verifying charges billed to a customer by a
vendor. A set of billing data associated with the charges is loaded
into a billing verification system that is accessible by both the
customer and the vendor via a distributed computer network. The
customer reviews the billing data via the billing verification
system to identify billing exceptions associated with any disputed
charges. A billing exception record is generated in the billing
verification system for each of the billing exceptions. The vendor
is then notified of the billing exceptions. The vendor reviews and
responds to the billing exceptions via the billing verification
system. A billing exception response record is generated for each
vendor response. The customer is then notified of the vendor
response.
[0010] According to another aspect of the present invention, there
is provided a method of verifying repair charges billed to an
equipment owner by a repair agent. A set of billing data associated
with the repair charges is loaded into a billing verification
system that is accessible by both the equipment owner and the
repair agent via a distributed computer network. The equipment
owner reviews the billing data via the billing verification system
to identify billing exceptions associated with any disputed repair
charges. A billing exception record is generated in the billing
verification system for each of the billing exceptions. The repair
agent is then notified of the billing exceptions. The repair agent
reviews and responds to the billing exceptions via the billing
verification system. A billing exception response record is
generated for each repair agent response. The equipment owner is
then notified of the repair agent responses.
[0011] According to another aspect of the present invention, a
system is provided for verifying vendor charges billed to a
customer. The system includes a billing verification database and
means for loading a set of billing data associated with the charges
into the database. A customer graphical user interface is in
communication with the database and is operable to facilitate
customer review of the billing data to identify a plurality of
billing exceptions associated with a plurality of disputed charges
and to generate a billing exception record in the database for each
of the billing exceptions. A vendor graphical user interface is in
communication with the database and is operable to facilitate
vendor review of the billing exception records to generate a
billing exception response record in the database for each of the
reviewed billing records.
[0012] The invention, and its objects and advantages, will become
more apparent in the detailed description of the preferred
embodiment presented below.
BRIEF DESCRIPTION OF THE DRAWINGS
[0013] The subsequent description of the preferred embodiments of
the present invention refers to the attached drawings, wherein:
[0014] FIG. 1 shows a block diagram depicting a billing
verification system according to one presently preferred embodiment
of the invention;
[0015] FIG. 2 shows a block diagram depicting a billing
verification system according to another presently preferred
embodiment of the invention;
[0016] FIG. 3 shows a flow diagram illustrating a method of
verifying charges billed by a vendor to a customer according to
another presently preferred embodiment of the invention;
[0017] FIG. 4 shows a flow diagram illustrating, from an equipment
owner's perspective, a method of verifying repair charges billed by
a repair agent to the equipment owner according to another
presently preferred embodiment of the present invention;
[0018] FIG. 5 shows a railcar owner menu screen display from an
equipment owner graphical user interface of a billing verification
system according to another presently preferred embodiment of the
invention;
[0019] FIG. 6 shows a billing exception header screen display from
the equipment owner graphical user interface;
[0020] FIG. 7 shows a billing exception record screen display from
the equipment owner graphical user interface;
[0021] FIG. 8 shows an exception document attachment screen display
from the equipment owner graphical user interface;
[0022] FIG. 9 shows a flow diagram illustrating, from a repair
agent's perspective, a method of verifying repair charges billed by
the repair agent to an equipment owner according to another
presently preferred embodiment of the present invention;
[0023] FIG. 10 shows a repair agent menu screen display from a
repair agent graphical user interface of a billing verification
system according to another presently preferred embodiment of the
invention;
[0024] FIG. 11 shows a billing exception header screen display from
the repair agent graphical user interface;
[0025] FIG. 12 shows a billing exception response screen display
from the repair agent graphical user interface;
[0026] FIG. 13 shows a response comment screen display from the
repair agent graphical user interface; and
[0027] FIG. 14 shows a summary report screen display from the
repair agent graphical user interface.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0028] Referring now to the accompanying drawings, FIG. 1 shows a
block diagram depicting an exemplary billing verification system
100 according to one presently preferred embodiment of the
invention. In this embodiment, the billing verification system 100
preferably is controlled and operated by a customer, represented
for purposes of this figure as a dotted block 102. The customer is
billed for goods or services by one or more vendors 104 that
interface with the system via computer workstations. The system 100
is useful for customers 102 and vendors 104 from a wide variety of
industries. For example, the customer 102 may be an equipment owner
whose railcars are repaired by one or more repair agents acting as
vendors 104.
[0029] In the embodiment of FIG. 1, the customer 102 maintains a
server 106 and a database 108. The database 108 in the present
embodiment contains billing data relating to charges billed by the
vendors 104 to the customer 102. The data includes billing
exception records and billing exception response records, as
described more fully below. The billing data is accessible by the
customer 102 and, perhaps to a more limited extent, the vendors
104, via the server 106. The billing data, which is based on bills
sent by the vendors 104 to the customer 102, may be loaded into the
database 108 in a number of ways. For instance, a vendor 104 may
provide the bill in an electronic file that is uploaded to the
server 106, which loads the billing data from the electronic bill
file into the database 108. Alternatively, the customer 102 may
load the billing data into the billing verification system 100 from
a bill received from a vendor 104. The vendor 104 may provide the
bill in traditional hardcopy format, or it may provide the bill in
an electronic bill file stored on a magnetic tape or other storage
media. If the bill is provided in hardcopy format, a customer
operator manually enters the billing data into the database 108. In
the case of an electronic bill file, the billing data may be
automatically transferred from the magnetic tape to the database
108.
[0030] Once the billing data is loaded into the database 108, the
customer accesses the billing data via a workstation 110 that is
connected to the server 106 via a distributed computer network 112,
such as an intranet, local area network, or, preferably, the
Internet. Alternatively, the customer workstation 110 may be
connected directly to the server 106. Access to the server 106
preferably is controlled via an authentication and access control
procedure. Through the workstation 110, the customer is able to
review the billing data and generate exceptions, as described more
fully below. Preferably, the server 106 generates a customer
graphical user interface in the form of custom web pages that
provide access to the billing data. These web pages are viewable by
the customer via a browser application resident on the customer
workstation 110. The server 106 also communicates with the customer
accounts payable system 114, preferably via the internal
distributed computer network 112.
[0031] Although only one customer workstation 110 is shown in FIG.
1, the system 100 may be accessible to various customer
representatives via a number of different workstations 110. For
instance, if it is necessary or helpful for customer field
representatives in remote locations to review the billing data,
they may do so via customer workstations 110 connected to the
server 106 via a distributed computer network 112, such as the
Internet. In this way, various customer employees are provided
convenient and efficient access to the billing data for purposes of
expedited review.
[0032] As an alternative to loading the billing data directly into
the database 108, the customer may first load the billing data into
a mainframe accounting system 116. This alternative provides a
transition system for customers that have traditionally processed
vendor billing data via a mainframe accounting system 116. For
instance, the customer 102 may first review the billing data and
generate exceptions on the mainframe accounting system 116. The
resulting processed data is then loaded into the database for
review by the vendors 104. After a transition period, the customer
102 may eliminate the mainframe accounting system 116 and process
all billing data via the server 106 and the database 108.
[0033] When the customer 102 generates exceptions to billing data,
billing exception records are created and eventually stored in the
database 108. Once the customer 102 has generated exceptions to
billing data provided by a particular vendor, the exceptions are
released, or made available, to that vendor via the server 106. The
vendor then reviews the relevant billing exception records by
accessing the server 106 via an external distributed computer
network 118, such as an intranet or preferably the Internet. Again,
access to the server 106 preferably is controlled via an
authentication and access control procedure. The server 106
provides a vendor graphical user interface, preferably in the form
of custom web pages that are viewed by the vendor 104 via a browser
application resident on a workstation maintained by the vendor 104.
The server 106, restricts vendor access to only those billing
exception records that relate to billing data for that particular
vendor. The authentication and access control procedure ensures
that one vendor is not allowed access to other vendors' billing
data. After reviewing the billing exception records, the vendor may
approve or disapprove the exceptions, as described more fully
below.
[0034] The system depicted in FIG. 1 preferably is controlled and
operated by the single customer 102, but provides access to
multiple vendors 104. Each vendor may have a variety of employees
that require access to the billing verification system 100. For
instance, if it is necessary or helpful for vendor field
representatives in remote locations to review the billing
exceptions in order to confirm or deny their legitimacy, they may
do so via computer workstations that connect to the server 106 via
a distributed computer network 118, such as the Internet. In this
way, various vendor employees are provided convenient and efficient
access to the billing data for purposes of expedited review of the
billing exceptions.
[0035] The block diagram shown in FIG. 2 depicts an alternative
billing verification system 200 according to another presently
preferred embodiment of the invention. The billing verification
system 200 depicted in FIG. 2 provides billing verification
services to a number of different customers 102. In this way, the
billing verification system 200 of FIG. 2 may act as an
industry-wide clearinghouse for billing exceptions. The billing
verification system 200 itself may be controlled and operated by a
customer 102 or by a third-party service provider.
[0036] Operation of this billing verification system 200 is similar
to that of the system 100 shown in FIG. 1. Billing data is uploaded
to the database 108 either by a customer 102 or a vendor 104. The
customer 102 then accesses the billing verification system 200 via
a distributed computer network 118, such as the Internet. The
customer 102 then reviews the billing data, and generates any
necessary billing exception records through use of the customer
graphical user interface. The vendor 104 also accesses the billing
verification system 200 via the distributed computer network to
review the billing exception records via the vendor graphical user
interface. As described above, the authentication and access
control procedure restricts customer and vendor access to only the
billing data that relates to that customer 102 or vendor 104.
Again, multiple employees of both the customers 102 and the vendors
104, perhaps in remote locations, may access the billing
verification system through workstations connected to the server
106 via the Internet.
[0037] Operation of these billing verification systems 100, 200
will now be described with reference to FIGS. 3-13. Unless
otherwise noted, the discussion will be applicable to both the
billing verification system 100 of FIG. 1 and the billing
verification system 200 of FIG. 2.
[0038] The flowchart shown in FIG. 3 illustrates a method of
verifying charges billed by a vendor 104 to a customer 102
according to one preferred embodiment of the invention. The
following description of the method refers generally to customers
102 and vendors 104. Because the method is applicable to a wide
variety of industries, the vendors 104 may represent parties that
provide any of number of different products or services to the
customers 102. The method involves a billing verification system
100, 200, as described above. For purposes of this method, the
billing verification system 100, 200 may be controlled and operated
by a customer 102, a vendor 104, or a third-party.
[0039] First, the billing data is loaded into the billing
verification system 100, 200 in step 302. Depending on the format
in which the billing data is provided by the vendor 104, the data
may be loaded automatically from an electronic bill file or it may
be entered manually from a hardcopy bill. Except in the case of the
transition system described above, the billing data resides in the
database 108 once it is loaded. The customer then accesses the
database 108 and reviews the billing data to identify any billing
exceptions in step 304. Customer review of the billing data in step
304 may be performed manually by a customer audit representative,
automatically by a computerized auditing system, or by a
combination of both manual and automatic review. In addition,
multiple customer employees, such as field representatives in
remote locations, may access the billing verification system 100,
200 to review the billing data. In step 306, for each billing
exception identified by the customer, the billing verification
system 100, 200 generates a billing exception record in the
database 108. The billing exception record may contain information
identifying the bill to which an exception is taken, the amount of
the exception, and the reasons justifying the exception. The vendor
104 is then notified of the customer's billing exceptions in step
308. Preferably, this notification is via an electronic mail
message generated by the billing verification system 100, 200 and
sent to the vendor 104.
[0040] The vendor 104 then accesses the database 108 and reviews
the billing exception records in step 310 to identify acceptable
billing exceptions. Like the customer review, vendor review may
include review by a number of vendor employees, such as field
representatives in remote locations. The vendor may approve,
disapprove, or partially approve each billing exception. In each
case, the billing verification system 100, 200 generates a billing
exception response record in the database 108. The billing
exception response record may contain information indicating
whether the exception has been approved or disapproved, as well as
a reason for the approval or disapproval. If the exception is
partially approved, the billing exception response record also may
include the partially approved dollar value. The billing
verification system 100, 200 then notifies the customer of the
vendor's billing exception responses in step 314. Like the vendor
notification, customer notification preferably is via an electronic
mail message generated by the billing verification system 100, 200
and sent to the customer.
[0041] In another preferred embodiment of the present invention,
the billing verification system 100, 200 is used in the specific
industry of railcar repair. In this embodiment, the billing
verification system 100, 200 is used to process billing exceptions
for railcar repair charges billed by a repair agent to a railcar
equipment owner. The repair agent serves as a vendor 104 of repair
services to its customer 102, the railcar owner. This embodiment of
the invention, as viewed from the railcar owner's perspective, will
now be discussed with reference to FIGS. 4-8.
[0042] The flow diagram shown in FIG. 4 illustrates a transition
method of verifying repair charges using both a mainframe
accounting system 116 and the billing verification system 100, as
described above with reference to FIG. 1. The method begins with
the step 402 of loading billing data from billing repair cards into
the mainframe accounting system 116. Repair agents provide billing
data to railcar owners in the form of billing repair cards. A
billing repair card indicates, among other things, the railcar
number, the kind of car, the repair date and location, and
description and cost of the necessary parts and labor. The format
of billing repair cards is governed by the AAR Interchange
Rules.
[0043] As described above, the billing data may be loaded into the
mainframe accounting system 116 in a number of ways. If the billing
repair cards are provided in hardcopy format, the railcar owner may
manually enter the billing data via a data entry interface. If the
billing repair cards are provided in an electronic file, the
billing data may be uploaded to the system automatically.
[0044] After the billing data is loaded into the mainframe
accounting system 116, the railcar owner reviews the billing data
for any incorrect, or disputed, repair charges in step 404. For
each disputed repair charge identified in step 404, a billing
exception record is generated in step 406. In step 408, the railcar
owner determines whether all billing repair cards for a particular
time period have been reviewed. If not, the railcar owner returns
to step 404 to review the next billing repair card. Once the
railcar owner has reviewed all billing repair cards, the method
proceeds to step 410 in which the billing exception records are
transferred to the billing verification system 100.
[0045] Using the billing verification system 100, the railcar owner
may perform a final review of the billing exception records in step
412. The railcar owner accesses the billing verification system 100
via a railcar owner graphical user interface. The graphical user
interface displays information and allows the railcar owner to
interact with the interface by using a pointing device to click on
buttons and hypertext links. A similar graphical user interface is
provided for the repair agent, as described more fully below.
[0046] An example of a railcar owner menu screen display 500 from
an exemplary railcar owner graphical user interface is shown in
FIG. 5. Under the Auditor Review section 502, the railcar owner may
click on hypertext links to select and view billing exception
records for various repair agents and time periods. The billing
verification system 100, 200 may contain billing data for all
repair agents that perform repairs for the railcar owner. Selecting
billing exception records for a particular repair agent and a
particular time period preferably causes the railcar owner
graphical user interface to display a billing exception header
screen display 600, an example of which is shown in FIG. 6. A
header area 602 of the display 600 shows summary information
relating to the billing repair cards and billing exceptions,
including bill number, account date, received date, total bill
amount, and total exception amount. A search area 604 provides
options for selecting billing exception records that correspond to
certain criteria, such as car number, exception amount, and repair
location (SPLC). When the railcar owner clicks on the "SEARCH"
button 606, the graphical user interface displays a billing
exception record screen display 700, an example of which is shown
in FIG. 7. A repair header area 702 of the display 700 shows, among
other things, the railcar number, the date of repair, and the
location at which the car was repaired. A repair description area
704 of the display 700 shows line item descriptions of the parts
and labor required for the repair. Each repair line item begins
with a repair line number that is used to reference billing
exceptions. A billing exception area 706 of the display 700 shows
exception line item descriptions of any exceptions to the repair
charges. The exception line item begins with an exception line
number that references the repair line number associated with the
repair line item to which an exception is taken. For instance, in
the display 700 of FIG. 7, an exception is shown for repair line
item number seven, which is described as "LABOR, JACK CAR". The
exception line item description indicates that an exception is
taken because the repair agent provided no justification for
jacking the car.
[0047] The repair header area 702, repair description area 704, and
billing exception area 706 preferably are formatted in a manner
that complies with the AAR Interchange Rules governing billing
repair cards. A navigation area 708 is also included in the billing
exception record screen display 700. By clicking the buttons in the
navigation area 708, the railcar owner is able to navigate between
different billing exception records.
[0048] If necessary, the railcar owner may attach electronic
documentation to support an exception in step 414 of the method
illustrated in FIG. 4. This may be accomplished by clicking the
"MATL", "DUP", or "OTH" hypertext links in the appropriate
exception line item of the exception area 706 shown in FIG. 7.
Clicking these links causes the graphical user interface to display
an exception document attachment screen display 800, an example of
which is shown in FIG. 8. The railcar owner locates and selects the
document to be attached, or enters the location of the document in
the path field 802, and then clicks the attach button 804. In this
way, the railcar owner may attach emails, drawings, reports, and
scanned documents to the exception line item. Preferably, the
"MATL" hypertext link is used to attach copies of a materials
requisition that show the railcar owner already paid for the parts
billed. Similarly, when a repair agent inadvertently bills a
railcar owner twice for the same repair, the "DUP" link may be used
to attach copies of the duplicate billing repair card. The "OTH"
link may be used to attach any other form of supporting
documentation.
[0049] The hypertext links labeled "MATL", "DUP", and "OTH" in
repair line item number seven of the repair description area 704
shown in FIG. 7 indicate that supporting documentation of all three
forms has been attached to the billing exception record associated
with that repair line item. Clicking on any of these three links
causes the graphical user interface to display the corresponding
attached documentation.
[0050] In step 416 of the method illustrated in FIG. 4, the railcar
owner determines whether all necessary documentation has been
attached to the billing exception record. If not, additional
documentation is attached in step 414. Once all documentation has
been attached, the method proceeds to step 418, in which it is
determined whether all billing exception records have been
reviewed. If not, the railcar owner returns to step 412 to review
the next billing exception record. Once all billing exception
records have been reviewed, the railcar owner releases the billing
exception records to the repair agent in step 420 by clicking on
the "RELEASE" button 608 shown in the billing exception header
screen display 600 of FIG. 6. Until this time, the billing
exception records are not accessible by the repair agent. Once
released in step 420, however, the billing exception records become
available to the repair agent via the billing verification system
100, and the repair agent is notified of their availability in step
422. Preferably, the billing verification system 100, 200 provides
notification by generating an electronic mail message and sending
the message to the repair agent.
[0051] The preceding discussion addressed a transition method of
verifying railcar repair charges from the railcar owner's
perspective. The transition method is useful for railcar owners as
they transition from processing billing exceptions via a mainframe
accounting system 116 to processing exceptions solely via a billing
verification system 100, 200. Once a railcar owner has completely
transitioned to the billing verification system 100, 200, the
method illustrated in FIG. 4 may be simplified. The first
simplification is that steps 402 through 408 may be performed via
the billing verification system 100, 200 rather than the mainframe
accounting system 116. As a result, the billing data from the
billing repair cards may be entered directly into the billing
verification system 100, 200, and the billing exception records may
be created directly in the database 108. In addition, the repair
agent optionally may upload the billing data from an electronic
file directly to the billing verification system database 108. The
second simplification is that step 410, transferring the billing
exception records from the mainframe accounting system 116 to the
database 108, becomes unnecessary. In addition to these
simplifications, transitioning completely to the billing
verification system 100, 200 enables multiple customer employees,
such as field representatives in remote locations, to review the
billing data and identify disputed charges by accessing the billing
verification system 100, 200.
[0052] The method of verifying railcar repair charges will now be
described from the repair agent's perspective with reference to
FIGS. 9-13. After the billing verification system 100, 200 sends
notification to the repair agent that the billing exception records
are available, the repair agent accesses the billing verification
system 100, 200 in step 902. A repair agent graphical user
interface presents the repair agent with a repair agent menu screen
display 1000, such as the example shown in FIG. 10. From this
display 1000, the repair agent may select billing exception records
relating to a particular railcar owner and time period by clicking
on the appropriate hypertext link. The billing verification system
100 of FIG. 1 contains only one railcar owner's billing exception
records. The billing verification system 200 of FIG. 2, however,
may contain billing exceptions records for all railcar owners for
which the repair agent performs repairs.
[0053] After the repair agent clicks one of the hypertext links
relating to a particular railcar owner and a particular time period
in the repair agent menu screen, the graphical user interface
presents a billing exception record header screen display 1100, an
example of which is shown in FIG. 11. A header area 1102 of the
display 1100 displays information such as the bill number, a
control number field 1104, account date, received date, total bill
amount, total exception amount, and total CBA amount. A search area
1106 provides options for selecting billing exception records that
correspond to certain criteria, such as car number, exception
amount, and repair location (SPLC). When the repair agent clicks on
the "SEARCH" button 1108, the graphical user interface displays the
first billing exception response screen display 1200, an example of
which is shown in FIG. 12.
[0054] A header area 1202 of the display 1200 shows, among other
things, the railcar number, the date of repair, and the location at
which the car was repaired. A billing exception area 1204 of the
display 1200 shows a line item description of the exception. The
exception line item begins with an exception line number that
references the repair line number associated with the repair line
item on the original billing repair card to which an exception is
taken. The display 1200 also includes a repair agent response area
1206 in which the repair agent may select a response to the
exception. Preferably, the repair agent is presented with three
possible responses. The repair agent may allow the exception,
disallow the exception, or partially allow the exception. If the
exception is partially allowed, the repair agent must designate a
partially allowed exception amount. The repair header area 1202,
billing exception area 1204, and repair agent response area 1206
preferably are formatted in a manner that complies with the AAR
Interchange Rules governing billing repair cards.
[0055] Also within the response area 1206, the repair agent may
include comments supporting or explaining the response (step 906 of
the method illustrated in FIG. 9). This is accomplished by clicking
on the "COMMENTS" hypertext link, which causes the graphical user
interface to display a response comments box 1302, and example of
which is shown in the comments screen display 1300 of FIG. 13. The
comments are added to the "COMMENTS" field in the response area
1206 of FIG. 12 after the repair agent clicks the "ADD" button 1304
in the response comments box 1302. The repair agent optionally may
attach supporting documentation in step 908 in a manner similar to
that in which the railcar owner attaches supporting documentation
as described above.
[0056] The billing verification system 100, 200 may accommodate
varying levels of review by different representatives of the repair
agent. This is particularly useful because field representatives of
the repair agent may need to be consulted to confirm certain
information related to repairs that were performed in the field.
The level of review for different repair agent representatives is
governed by the authentication and access control procedure. For
instance, a repair agent manager and various repair agent field
representatives may be granted different authentication
credentials, such as usernames and passwords. Based on these
credentials, the authentication and access control procedure
preferably grants the manager access to all billing exception
records relating to the repair agent. The field representatives,
however, are preferably only granted access to those billing
exception records that relate to their particular field repair
facility or category of appropriate repair. In this case, the
manager may notify each field representative when the billing
exception records are available for their review. The field
representatives then notify the manager when they have completed
their review. Alternatively, the billing verification system 100,
200 may generate the appropriate notification messages. Once a
field representative has completed review of billing exceptions and
prepared the appropriate responses, those billing exception records
may become inaccessible to the field representative, although the
repair agent manager still may access them. At any time, the
manager may review the status of pending billing exceptions
according to various categories, such as completed responses,
field-completed responses, and in-process responses. For instance,
the manager may review an exception processing status report screen
display 1400, an example of which is shown in FIG. 14, by clicking
the "STATUS RPT" button on the exception record header screen
display 1100 of FIG. 11. The display 1400 includes a processing
summary area 1402 that indicates how many of the exceptions for
each location (SPLC) have been completed, how many have been
field-completed, and how many are currently in-process. The summary
area 1402 also includes information regarding the dollar amounts of
the exceptions that have been allowed, disallowed, and partially
allowed. Preferably, the manager reviews all billing exception
responses before they are released to the railcar owner, as
described below.
[0057] In step 910 of the method illustrated in FIG. 9, the repair
agent submits the exception response by clicking either the
"SUBMIT" button 1208 or the "SUBMIT/NEXT" button 1210 on the
billing exception response screen display 1200. The "SUBMIT/NEXT"
button 1210 also causes the graphical user interface to display a
billing exception response screen for the next billing exception to
be reviewed. After the repair agent clicks on either of these two
buttons, the billing verification system 100, 200 generates a
billing exception response record in the database 108 (step 912 of
the method illustrated in FIG. 9). It will be understood in the art
that the billing exception response record may be an independent
database record or it may be contained within the corresponding
billing exception record.
[0058] The next step 914 is to determine whether the repair agent
has reviewed all billing exception records. If not, the method
returns to step 904, in which the repair agent reviews the next
billing exception record in the same manner as described above.
Once the repair agent has reviewed all of the billing exception
records for a particular railcar owner and time period, the repair
agent completes the exception review process in step 916 by
clicking the "COMPLETED" button on the exception header review
screen display 1100 of FIG. 11. The railcar owner is then notified
of the billing exception responses in step 918. At this time, the
billing exception response records become available for review by
the railcar owner. The railcar owner accesses the billing exception
response records via the "RAILROAD COMPLETED" hypertext link 504 on
the railcar owner menu screen display 500 shown in FIG. 5.
[0059] Preferably, before the railcar owner is notified that the
billing exception response records are available for review, the
repair agent designates a control number, or credit billing
authority number, to be associated with the bill and its
corresponding billing exceptions. For instance, the repair agent
may designate a control number in the control number field 1104 of
the billing exception header screen 1100 shown in FIG. 11. The
repair agent may update the control number by clicking the "UPDATE
CBA" button 1110. The railcar owner then uses this control number
to take a credit on its repair charge account with the repair agent
or to counter-bill the repair agent in accordance with the credit
billing authority procedures provided by the AAR Interchange Rules.
For example, the billing verification system 100, 200 may generate
a message that is sent to the railcar owner's accounts payable
system 114 indicating that the appropriate credit may be deducted
from the next bill paid to that repair agent.
[0060] If necessary, the methods described above may include a
number of review iterations by both the customer (i.e. railcar
owner) and the vendor (i.e. repair agent). For instance, if a
vendor disapproves a customer's billing exception, the customer may
reply with further documentation supporting the exception. The
vendor may then provide an additional response. This iterative
process may continue until all disputed charges are resolved.
[0061] The invention has been described in detail with particular
reference to preferred embodiments thereof and illustrative
examples, but it will be understood that variations and
modifications can be effected within the spirit and scope of the
invention.
* * * * *