Electronic cargo payment system

Embodiments of the disclosure generally relate to an electronic cargo payment system and methods for electronically and automatically processing electronic payments for goods shipped by carriers for shippers. In embodiments, the accounts receivable system of the carrier transfers one or more invoices to a central payment system. The central payment system stores and organizes the invoices. A shipper communicates with the central payment system to view invoices related to that shipper. Upon approval of the invoice, the central payment system can automatically pay the invoice for the shipper and to the carrier.

BACKGROUND OF THE INVENTION

International trade requires the shipment of goods and services between various ports located in numerous countries. Generally, a shipper hires a carrier to move goods from one location to another. A shipper can be an importer buying goods from a manufacturer or distributer in another location. A shipper may also be an exporter shipping goods as a distributor or manufacturer to a buyer in another location. The carrier is generally the entity that owns and/or operates the equipment used to ship the goods. For example, the carrier may be a company that operates cargo ships that transport shipping containers over the oceans.

To pay for the cost of the shipment, a carrier will generally send a paper invoice to the shipper. The shipper reviews the invoice and can remit payment by check, money order, or bank transfer. These payment options are generally slow and cost additional money for couriers, mail, etc. If the shipper disputes some item in the invoice, the shipper may send the carrier a letter disputing the amount in the invoice. The resolution process is slow and expensive as the carrier and shipper send letters between the parties to come to a resolution.

It is in view of these and other considerations not mentioned herein that the embodiments of the present disclosure were envisioned.

BRIEF SUMMARY OF THE INVENTION

Embodiments of the disclosure generally relate to an electronic cargo payment system and methods for electronically and automatically processing electronic payments for goods shipped by carriers for shippers. In embodiments, the accounts receivable system of the carrier transfers one or more invoices to a central payment system. The central payment system stores and organizes the invoices. A shipper communicates with the central payment system to view invoices related to that shipper. Upon approval of the invoice, the central payment system can automatically pay the invoice for the shipper and to the carrier.

DETAILED DESCRIPTION OF THE INVENTION

Embodiments described herein provide for an electronic cargo payment system. The electronic cargo payment system includes a central payment system that can communicate with two or more carriers (e.g., Crowley Maritime Corporation) and two or more shippers (e.g., Walmart). The central payment system allows the carriers and shippers to register with the central payment system to effectuate the payment of cargo shipments. After registration, the carrier can upload one or more invoices to the central payment system. The invoices may be for different shippers or may be for the same shipper. After uploading the invoices, the central payment system organizes and stores the invoice information to allow for access by the shipper. The shipper may be informed about the available invoices and communicate with the central payment system. In reviewing the invoices, the shipper can approve the invoice. In response to the approval, the central payment system can automatically pay the invoice for the shipper.

For example, Walmart can contract with Crowley to ship 10 tons of bananas from Puerto Rico. After or during shipment, Crowley generates an invoice from Crowley's accounts receivable system and sends the invoice for the shipment to the central payment system. The invoice identifies Walmart as the shipper and Crowley as the carrier. The invoice also includes the itemized charges and an amount to be paid by Walmart. The invoice information can be stored in the central payment system. The central payment system may then alert Walmart to the reception of the invoice. For example, an email may be sent to Walmart's accounting department. The alert may not be needed as Walmart may interface with the central payment system periodically and regularly. Walmart communicates with the central payment system to view the invoice information. For example, Walmart logs on to a website provided by the central payment system and can view invoices in a webpage. Walmart can approve the invoices. Upon approval, the central payment system can request an ACH transfer from an account associated with Walmart to an intermediary account. Then, the central payment system can make an ACH transfer from the intermediary account to an account associated with Crowley. In this way, all approvals and payments are electronic. Further, payments are automatic between the parties upon approval of the invoice.

Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits may be shown in block diagrams in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments. In some embodiments, a computing system may be used to execute any of the tasks or operations described herein. In embodiments, a computing system includes memory and a processor and is operable to execute computer-executable instructions stored on a computer-readable medium that define processes or operations described herein.

Two or more components described herein may be in communication. To be in communication includes any form of electrical or electronic connection, either wired or wireless, allowing two components to exchange signals, data, information, etc. The communications may be made using any protocol or format including one of, but not limited to, TCP/IP, 802.11(b), Electronic Data Interchange For Accounting (EDIFACT), Web services, etc. The hardware and/or software used in a communication interface allows for the communication between components. The hardware and/or software can include transceivers, MODEMs, or other types of network interface equipment.

An embodiment of an electronic cargo payment system100for providing electronic payment for a cargo shipment is shown inFIG. 1. The electronic cargo payment system100can include a central payment system108in communication with a carrier116and a shipper118. In embodiments, the central payment system108is in communication with two or more carriers116and two or more shippers118. The central payment system108can communicate with the carrier116and/or shipper118over a network112. The network may be a private or public network. In embodiments, the network112is the Internet.

The central payment system108is a computing system or device (as described in conjunction withFIG. 7) that interacts with the carrier116and/or the shipper118. The central payment system108is a software and/or hardware system to electronically receive invoices, electronically approve the invoices, and automatically pay the invoices. The central payment system108can be a system associated with the carrier116or shipper118. However, the central payment system108can be a separate system not associated with either the carrier116or the shipper118.

In embodiments, the central payment system108registers the carrier116and/or the shipper118and stores the registration information in a database110. The database110can include any hardware and/or software to logically store information received from or provided to the carrier116, the shipper118, or a merchant acquirer106. For example, the database110is a relational database, such as Microsoft Access, stored across an array of memory devices. the database110can include a computing system (as described in conjunction withFIG. 7) for storing and accessing the memory storing the data.

In embodiments, the central payment system108is also in communication with a merchant acquirer106. The merchant acquirer106may use a second communications channel that is proprietary or restricted to allow the central payment system108to communicate with a merchant acquirer106privately and securely. The second communications channel may be a cellular network, a wireless LAN or WAN, or other communication system.

The merchant acquirer106, in embodiments, is an entity that processes credit or debit authorizations. For example, the merchant acquirer106is VISA® or MASTERCARD®. In other embodiments, the merchant acquirer106is a financial institution, for example, a bank, that processes credit or debit authorizations and/or approves debits or credits to a consumer's financial account. The merchant acquirer106may have a predefined relationship with the central payment system108. In embodiments, a merchant acquirer106receives an authorization request and passes the request to a consumer payment issuing institution102(simply referred to as the issuing bank102). The issuing bank102, in embodiments, is a financial institution that approves transactions for a consumer.

In operation, the central payment system108receives invoice information114from the carrier116over the network112. The central payment system108analyzes the invoice information114and stores the information in the database110. The shipper118may then communicate with the central payment system108. In an embodiment, the shipper118is informed of the new invoice by email or other communication to the shipper118. The shipper118logs on to a website provided by the central payment system108. The logon allows the central payment system108to determine the identity of the shipper118. The invoices related to the shipper118are identified with the logon name or an identifier related to the shipper118. The invoices are presented to the shipper118on the website.

The shipper118can then review the invoice(s) and approve the invoices for payment. If the shipper118approves the invoice, the central payment system108can retrieve payment information related to the shipper118from the database110. For example, the central payment system108retrieves the bank account number, routing number, and other information required for an ACH payment. Then, the central payment system108can send a transfer request over an ACH network to transfer the amount of the invoice from the shipper's account to an intermediary account associated with the central payment system108.

The merchant acquirer106receives the payment information from the central payment system108. In embodiments, the merchant acquirer106may then approve the transaction by determining the consumer can pay for the transaction and then issues an authorization. The payment information is sent on to the issuing bank102, which authorizes the transaction, over a switching network104(e.g., the ACH network). In embodiments, the merchant acquirer106further sends the authorization to the central payment system108. The central payment system108can then forward the authorization to the shipper118and/or carrier116. In other embodiments, the issuing bank102approves the transaction. If approved, the issuing bank102can transfer the funds for the invoice to the intermediary account of the central payment system108.

Upon receiving payment into the intermediary account, the central payment system108can retrieve payment information related to the carrier116from the database110. For example, the central payment system108retrieves the bank account number, routing number, and other information required for an ACH transfer to the carrier116. Then, the central payment system108can send a transfer request over an ACH network to transfer the amount of the invoice to the carrier's account from the intermediary account associated with the central payment system108.

The merchant acquirer106receives the payment information from the central payment system108. In embodiments, the merchant acquirer106may then approve the transaction by determining that the money in the intermediary account is sufficient to pay for the transaction and then issues an authorization. The payment information is sent on to the issuing bank102, which authorizes the transaction, over a switching network104(e.g., the ACH network). In embodiments, the merchant acquirer106further sends the authorization to the central payment system108. The central payment system108can then forward the authorization to the shipper118and/or carrier116. In other embodiments, the issuing bank102approves the transaction. If approved, the issuing bank102can receive the funds for the invoice from the intermediary account of the central payment system108.

Other payment methods are also possible including credit payments, debit transactions, etc. Regardless, upon approval of an invoice, the central payment system108can affect an automatic payment between the shipper118and carrier116. If the invoice is not approved, the central payment system108can provide a dispute resolution system (not shown) to negotiate the problems with the invoice.

An embodiment of a central payment system202is shown inFIG. 2. The central payment system202may be the same or similar to central payment system108(FIG. 1). The central payment system202can include software components or modules executed in a processor or hardware circuits formed in an application-specific integrated circuit, field-programmable gate array, or other hardware device. In embodiments, the central payment system202includes a shipper communications interface208, a carrier communication interface206, a synchronization component212, an invoice system210, and a payment system214.

The shipper communications interface208and/or carrier communication interface206provides communications between the shipper118(FIG. 1) and/or carrier116(FIG. 1), respectively, via network1204. Network1204may be the same or similar to network112(FIG. 1). The communications may be any format or by any protocol. In an embodiment, the shipper communications interface208and/or carrier communication interface206provide a web interface allowing a shipper118(FIG. 1) or carrier116(FIG. 1) to interact with the central payment system202through one or more web pages. The web pages may be generated by the shipper communications interface208or carrier communication interface206and sent to and rendered by the shipper118(FIG. 1) or carrier116(FIG. 1). Thus, the shipper communications interface208and/or carrier communication interface206can include a web server or other system for providing web pages. The shipper communications interface208and/or carrier communication interface206may also be able to receive inputs into the web pages via a message sent to the shipper communications interface208or carrier communication interface206.

The carrier communication interface206may include a translator. In embodiments, the carrier116(FIG. 1) sends invoice information114(FIG. 1) in a proprietary format from the accounts receivable system of the carrier116(FIG. 1). The translator may translate the information from the proprietary format to a common format. For example, the translator may translate the information into an XML document having standard fields with information input from the invoice information114(FIG. 1) into the standard fields. There may be a translator for each carrier116(FIG. 1). In other embodiments, the translation is completed by each carrier116(FIG. 1). Thus, each carrier116(FIG. 1) sends a standard format document to the central payment system202.

The synchronization component212can allow for synchronization of invoice information between the carrier116(FIG. 1) and the central payment system202. In embodiments, each carrier116(FIG. 1) may transfer invoice information114(FIG. 1) either in a batch or as separate invoices. A batch is two or more invoices that may be associated with one or more shippers118(FIG. 1). The carrier116(FIG. 1) can determine a time to batch and transfer invoices. Thus, the transfer of invoice information may occur periodically, for example, every day at midnight.

This batched transfer can include the synchronization of information between the central payment system202and the carriers accounts receivable system116(FIG. 1). Thus, any changes, either in the central payment system202or the carrier116(FIG. 1), can be reflected in the other system. The synchronization component212component completes the synchronization by checking for invoice information that has changed since the last synchronization. For example, when an invoice is changed, either the central payment system202or the carrier116(FIG. 1) can mark and time stamp the change. The synchronization component212searches for and identifies files marks as changed. The time stamps can be compared to the date and time of the last synchronization. If the time stamp is more recent (e.g., is later in time than the synchronization date and time), the change can be sent to the carrier116(FIG. 1). The carrier116(FIG. 1) may conduct a similar procedure to send changes to the central payment system202. In alternative embodiments, the entire invoice may be resent rather than just the changes.

The invoice system210can provide the information for the web pages or communications to and from the shipper118(FIG. 1) and/or carrier116(FIG. 1). Further, the invoice system210may receive the inputs from the shipper118(FIG. 1) and/or carrier116(FIG. 1) to approve invoices and automatically pay the invoices. The invoice system210can receive the invoice information from the synchronization component212and store the information in the database216. The database216may be the same or similar to the database110(FIG. 1). Periodically or upon request, the invoice system210can receive a request from the shipper118(FIG. 1) to view invoice information associated with the shipper118(FIG. 1). The invoice system210may then determine an identifier for the shipper118(FIG. 1) and retrieve, from the database216, invoice information associated with the shipper identifiers. This information can be provided to the shipper118(FIG. 1) in a web page. The invoice system210may then receive any approval for an invoice. Upon receiving the approval, the invoice system210can instruct the payment system214to pay the invoice.

In embodiments, the payment system214communicates with the merchant acquirer106(FIG. 1) or other entity over network2218. Network2218may be a private network (e.g., the ACH network) or other network used to communicate payment information. The payment system214can format payment requests and transmit the payment requests based on information sent to the payment system214from the invoice system210. The payment system214may also receive authorizations for payment, payment completion messages, etc. that are reported to the shipper118(FIG. 1) or carrier116(FIG. 1). In embodiments, the received messages are ACH messages notifying the shipper118(FIG. 1) or carrier116(FIG. 1) that an ACH payment has been completed.

Embodiments of data structures used for communication of information to or from the central payment system108(FIG. 1) and/or for storage in the database110(FIG. 1) are shown inFIGS. 3A-3C. An embodiment of a data structure300to communicate or store invoice data is shown inFIG. 3A. The invoice data structure300can include one or more fields that contain information that directs a processor or other hardware component in the central payment system202(FIG. 2) to completed predetermined functions. The invoice data structure300can include a carrier identifier field302, a shipper identifier field304, an invoice header306, and/or invoice data308.

A carrier identifier302can be any identifier associated with the carrier116(FIG. 1).

For example, the carrier identifier302is a unique alphanumeric identifier assigned to the carrier116(FIG. 1) when the carrier116(FIG. 1) registers with the central payment system108(FIG. 1). In other embodiments, the carrier identifier302is a numeric, a GUI, a logon name chosen by the carrier116(FIG. 1), or other identifier. The carrier identifier302can be any type of identifier if the identifier is unique from other carrier identifiers302associated with carriers116(FIG. 1). Likewise, the shipper identifier304can be any identifier associated with the shipper118(FIG. 1). For example, the shipper identifier304is a unique alphanumeric identifier assigned to the shipper118(FIG. 1) when the shipper118(FIG. 1) registers with the central payment system108(FIG. 1). In other embodiments, the shipper identifier304is a numeric, a GUI, a logon name chosen by the shipper118(FIG. 1), or other identifier. As with the carrier identifier302, the shipper identifier304can be any type of identifier if the identifier is unique from other shipper identifiers304associated with other shippers118(FIG. 1).

The invoice header field306can include any identifying information associated with a particular invoice. It is possible to have two or more invoices associated with each pair of shipper118(FIG. 1) and carrier116(FIG. 1), as represented by ellipses310and312. The information in the invoice header306can differentiate a first invoice from a second invoice that are both associated with both the carrier116(FIG. 1) and shipper118(FIG. 1). Further, if there is only one invoice associated with the carrier116(FIG. 1) and shipper118(FIG. 1), the invoice header field306may be eliminated. In embodiments, the invoice header field306can include one or more of, but is not limited to, a unique identifier for the invoice (e.g., invoice number), a date of the invoice, a time of the invoice, a name for the invoice, etc.

Each invoice can include information about the invoice, which is included in an invoice data field308. The invoice data308can include one or more of, but is not limited to, the price of the invoice, the items in the cargo (e.g., the bill of lading), the date of delivery, the date of shipment, the weight of the cargo, the volume of the cargo, etc. The items in the invoice may each be identified by an identifier. The item identifier may be standard for each item across all invoices. As such, the central payment system202can organize and store the data in a standard format. Further, the item identifiers can allow disputes to be directed on an item by item basis.

A carrier registration data structure314is shown inFIG. 3B. The carrier registration data structure314can include a carrier identifier field316, a carrier information field318, and/or a carrier payment information field320. The carrier identifier field316can include the unique carrier identifier associated with the carrier. This identifier may be assigned to the carrier by the central payment system202upon registration of the carrier. In other embodiments, the carrier may choose the identifier. The carrier information field318can include biographical information for the carrier, including one or more of, but not limited to, the carrier's address, phone number, zip code, name, logo, hours of operation, etc. The carrier payment information320provides information necessary to allow the central payment system202to make automatic payments to the carrier. The carrier payment information320can include one or more of, but is not limited to, the carrier's bank account number, the routing number of the carrier's bank, the carrier's credit account number, the carrier's debit account number, indication of whether the carrier provides credit, etc.

A shipper registration data structure322is shown inFIG. 3C. Similar to the carrier registration data structure314, the shipper registration data structure322can include a shipper identifier field324, a shipper information field326, and/or a shipper payment information field328. The shipper identifier field324can include the unique shipper identifier associated with the shipper. This identifier may be assigned to the shipper by the central payment system202upon registration of the shipper. In other embodiments, the shipper may choose the identifier. The shipper information field326can include biographical information for the shipper, including one or more of, but not limited to, the shipper's address, phone number, zip code, name, logo, hours of operation, etc. The shipper payment information328provides information necessary to allow the central payment system202to make automatic payments for the shipper. The shipper payment information320can include one or more of, but is not limited to, the shipper's bank account number, the routing number of the shipper's bank, the shippers credit account number, the shipper's debit account number, indication of whether the shipper is provided credit by a carrier, etc.

An embodiment of a method400for registering a carrier or shipper is shown inFIG. 4. The method400may represent one or more steps of a computer-executable process that is executed by a processor. In embodiments, the method400will be explained with reference to components and data structures described in conjunction withFIGS. 1-3C. Generally, the method400begins with a start operation402and terminates with an end operation416. However, the steps shown inFIG. 4may represent only a subset of steps in the method400, and the steps shown may be preformed out of order.

The central payment system202receives a request from a shipper116or a carrier114to register in step404. The request can be the selection of a user interface device (e.g., selectable button) on a web page for the central payment system202. The request is received as a TCP/IP packet at the central payment system202. The central payment system202creates an identifier in step406. The central payment system202can create the carrier registration data structure314or the shipper registration data structure322in the database216. The identifier can be generated and stored in the carrier identifier field316or the shipper identifier field324. The identifier may be randomly generated and checked against existing identifiers in the database216. For example, after creating the identifier, the central payment system202conducts a query on the database216for the created identifier. If no result is returned from the database, the identifier is associated with the carrier or shipper and stored in the database216. However, if a result is returned, a new identifier is created and checked. This process may continue until an unique identifier is created. In other embodiments, the identifiers are sequential, and the next sequential identifier is assigned to the carrier or shipper.

The central payment system202may receive information about the shipper or carrier in step408. In response to receiving the request to register and/or the creation of the identifier, the central payment system202may send, via the shipper communications interface208or the carrier communication interface206, a web page requesting information. The information can be general information about the shipper or carrier. The response from the shipper or carrier (e.g., entries into the web page) may be a TCP/IP message. The information can be received in or stored in either the carrier information field318or the shipper information field326.

The central payment system202may then receive payment information about the shipper or carrier in step410. In response to receiving the request to register and/or the creation of the identifier and/or the receipt of information in step408, the central payment system202may send, via the shipper communications interface208or the carrier communication interface206, a web page requesting payment information. The shipper communications interface208or the carrier communication interface206may establish a secure connection to protect the payment information. The information can be payment information for the shipper or carrier. The response from the shipper or carrier (e.g., entries into the web page) may be a TCP/IP message. The payment information can be received in or stored in either the carrier payment information field320or the shipper payment information field328.

The central payment system202associates the information (payment or otherwise) with the identifier in step412. In embodiments, the central payment system202associates the information with the identifier by storing the information in the carrier registration data structure314or the shipper registration data structure322, in the database216, having the associated identifier. In other embodiments, the information is stored separately and a link or association between the identifier and the information is created in the database216.

In embodiments, the central payment system202allows a shipper to associate the shipper with carrier(s) and allows a carrier to associate the carrier with shipper(s) in step414. For example, a shipper can review the carriers registered with the central payment system202. The shipper can select one or more carriers that the shipper uses. The identifier for the shipper is then associated with the identifier for the carrier. The associations may be stored in the shipper information326. The associations allow the shipper control over which carriers it will allow to use the central payment system202for invoice presentment and payment. The central payment system202can also allow the carrier to associate with shippers in a similar manner.

An embodiment of a method500for receiving invoice information from a carrier is shown inFIG. 5. The method500may represent one or more steps of a computer-executable process that is executed by a processor. In embodiments, the method500will be explained with reference to components and data structures described in conjunction withFIGS. 1-3C. Generally, the method500begins with a start operation502and terminates with an end operation512. However, the steps shown inFIG. 5may represent only a subset of steps in the method500, and the steps shown may be performed out of order.

The central payment system202receives one or more invoices from a carrier116in step504. In embodiments, the carrier116sends invoice information114to the carrier communication interface206. The invoice information114may be received as part of a synchronization process executed by the synchronization component212. The invoice information114may represent one or more invoices. Invoice information114may be provided in an invoice data structure as described in conjunction withFIG. 3A. The central payment system202may then identify the shipper118and/or the carrier116associated with the invoice(s) in step506.

The central payment system202can parse the invoice information300. Then, the central payment system202may identify each shipper identifier304in the invoice information300. The parsed invoice information can then be stored by carrier identifier302and shipper identifier304pairs in step508. Thus, the central payment system202can organize and store the invoice information according to the shipper identifier304and the carrier identifier302. Each stored invoice may be identified by the invoice header information306. The central payment system202may then provide the invoices to the shippers in step510. An embodiment of a method600for providing invoices to the shippers is shown inFIG. 6.

The method600may represent one or more steps of a computer-executable process that is executed by a processor. In embodiments, the method600will be explained with reference to components and data structures described in conjunction withFIGS. 1-3C. Generally, the method600begins with a start operation602and terminates with an end operation620. However, the steps shown inFIG. 6may represent only a subset of steps in the method600, and the steps shown may be preformed out of order.

The central payment system202can receive a request to review invoice information in step604. The request may be received in response to an alert provided to a shipper from the central payment system202. For example, the central payment system202may change the start page of the web site provided to a shipper when the shipper logs on to the central payment system202. When the shipper logs on to the web site, the central payment system202can determine the identifier for the shipper and locate the identifier in the database216. If there is a new or unread invoice associated with the shipper identifier, the central payment system202can send the modified start page. A new or unread invoice may be determined by comparing the save data and time of the invoice with the last log on date and time. If the save date and time of the invoice are more recent than the last log on date and time, the central payment system202can determine that the invoice is new or unread. The start page can include a visual indicator that a new invoice associated with the shipper has been received.

Optionally, the central payment system202can provide one or more links to the one or more invoices in step606. In embodiments, the start page or other web page can include a selectable device that is a URL directed to an invoice. In other embodiments, the central payment system202receives a request to provide all invoice data. For example, the shipper selects a user interface device to view all invoice data. The central payment system202then provides one or more invoices in step608. The central payment system202can send a web page showing invoice data extracted from the database216. A shipper can review the invoice data and be provided with a user interface device to approve the invoice.

The central payment system202determines if an invoice is approved in step610. In embodiments, the central payment system202determines if the shipper selects the user interface device to approve the invoice. If the shipper does not approve the invoice, the method600proceeds NO to step612where the invoice is sent to a dispute resolution process. The shipper may be presented with a web page to enter the reasons for the dispute which can be provided to the carrier in step616. If the invoice is approved, the method600proceeds YES to step614.

The central payment system202can automatically pay the invoice in step614. An invoice system210of the central payment system202can receive the approval and forward the payment information from the invoice data308along with the carrier payment information320and shipper payment information328to the payment system214. The payment system214may determine the type of payment to make, for example, credit, ACH transfer, debit transaction, credit from the carrier, credit provided by the central payment system202, etc.

The preference of payment type may be determined from the carrier payment information320and/or shipper payment information328. The payment system214generates the payment message and sends the message to the merchant acquirer106or other system. The results of the payment transaction, whether successful payment or unsuccessful payment, are reported back to the invoice system210.

The central payment system202reports the disposition of the invoice in step616. In an embodiment, the invoice system210creates a web page that can be sent by either the shipper communication interface208or the carrier communication interface206. The web page includes a status of the invoice, for example, paid, approved, disputed, etc. When a shipper or carrier associated with the invoice logs on, the web page can be provided to the shipper116or carrier114. The web page may be provided upon requests such as when a shipper116or carrier114select a user interface device to see the status of one or more invoices. In other embodiments, the invoice system210generates an email, text message, or other message that is sent by the shipper communication interface208or the carrier communication interface206directly to the shipper116or carrier114.

After a first invoice is approved or disputed, a second or next invoice may be requested by the shipper116. The central payment system202can determine if there is another invoice to view in step618. In embodiments, if the shipper116wants to view another invoice, the shipper communication interface208receives a request to view another interface. For example, the shipper selects a user interface device on a web page to view all the invoices or to view a next invoice. The selection is received by the shipper communication interface208and sent to the invoice system210. If a selection to view another invoice is received, the method600proceeds YES back to step608. If no selection is received or a selection other than to view another invoice is received, the method600can proceed NO to step620.

An embodiment of a computer system700operable to perform as one or more components or in one or more systems as described herein is shown inFIG. 7. The computer system700can comprise a processor702that can execute software elements, components, modules, computer-executable processes or steps. The software elements can be stored within the working memory704. The software elements may include an operating system and/or other code, such as one or more application programs, which may execute the methods explained in conjunction withFIGS. 4, 5, and 6. The software elements may comprise computer programs of the disclosure and/or may be designed to implement methods of the disclosure and/or configure systems of the disclosure, as described herein.

Merely by way of example, one or more procedures described with respect to the method(s) discussed above might be implemented as code and/or instructions executable by a computer (and/or a processor within a computer). A set of these instructions and/or code might be stored on a computer-readable storage medium, such as the storage device(s)708. Storage device(s)708can be hard drives, ROM, RAM, or other memory comprised of any storage technology or using any memory application to store data or executable software components. In some cases, the storage medium might be incorporated within a computer system, such as the system700. In other embodiments, the storage medium might be separate from a computer system (i.e., a removable medium, such as a compact disc, etc.), and/or provided in an installation package, such that the storage medium can be used to program a general purpose computer with the instructions/code stored thereon. These instructions might take the form of executable code, which is executable by the computer system700and/or might take the form of source and/or installable code, which, upon compilation and/or installation on the computer system700(e.g., using any of a variety of generally available compilers, installation programs, compression/decompression utilities, etc.), then takes the form of executable code. System700can also include input and output devices706. Input devices can include cameras, microphones, keyboards, mice, etc. Output devices can include displays (e.g., LCD monitors), speakers, printers, etc.

The central payment system202provides advantages of the systems and methods previously used. For example, the central payment system202can electronically organize the payment of invoices for cargo shipments. This central payment system202can provide the interaction between multiple carriers and multiple shippers. Further, the central payment system202can automatically pay invoices approved by shippers. Thus, the central payment system202eliminates the need for sending payment by check, wire transfer, etc. Overall, the central payment system202make the payment of invoice for cargo shipments more efficient and effective.

The preceding description provides exemplary embodiment(s) only, and is not intended to limit the scope, applicability or configuration of the disclosure. Rather, the description of the exemplary embodiment(s) provide those skilled in the art with an enabling description for implementing an exemplary embodiment of the disclosure. It is to be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the disclosure as set forth in the appended claims.

An embodiment of a dispute resolution system800is shown inFIG. 8. The function of the dispute resolution system800shall be described with reference toFIGS. 8 through 10. A dispute resolution system800comprises a complaint/response receiver802in communication with a dispute generator804that is in communication with a dispute data database806.

Embodiments of methods900and1000for conducting a dispute resolution in a central payment system are shown inFIGS. 9 and 10. The methods900and1000begin with a start operation902and1002and terminate with an end operation912and1014. InFIG. 7, a complaint is received from the shipper in step904. The complaint is identified in the invoice in step906. A dispute is generated for the complaint in step908. This dispute is stored in step910. After a dispute is generated and stored, an alert is sent in step912.

InFIG. 10, a response from the carrier associated with the dispute is received in step1004. In response to receiving the response, a determination is made regarding whether the dispute is resolved in step1006. If and when the dispute is resolved, the method1000flows YES to end the dispute resolution process at step1014. When the dispute is not resolved, the method1000flows NO and a change to the dispute is determined in step1008. The change to the dispute is stored in step1010. An alert regarding the changed dispute is sent in step1012.

An embodiment of a historical data system1100is shown inFIG. 11. The function of the historical data system1100shall be described with reference toFIGS. 11 and 12. A historical data system1100comprises a dispute resolution aggregator1102in communication with a historical data database1106. The historical data database1106receives an input from an invoice aggregator1104. The historical data database1106is also in two-way communication with a query engine1110. The query engine1110receives input from an automated information component1108. The query engine1110is in communication with a report generator1112that produces historical outcome data.

An embodiment of a method1200for receiving invoice information from a carrier is shown inFIG. 12. The method1200begins with a start operation1202and terminates with an end operation1212. A request for action is received in step1204. The information associated with the action is extracted in step1206. Historical data is automatically queried in step1208. A historical outcome, based on the historical data, is reported in step1210.

An alternative embodiment of the electronic cargo payment system1300is shown inFIG. 13. Herein, a broker1304is interposed between the central payment system1302and one or more shippers, e.g., shipper #11306, shipper #21308, or shipper #31310.