MPI wants the invoice to skip the paper.

An invoice begins as something wonderfully useful: data. A seller’s system knows the customer, the amount and what was sold. Print that invoice, send it across town, and somebody at the other end may have to type the same information again. The numbers have made a journey. The work has multiplied. MPI’s software proposition starts with an objection to that journey: why should information that already exists have to become paper before another computer can use it?

Mega Pools, Inc., which uses MPI, is an Illinois information technology company with interests spanning finance, supply chains, warehouse systems and business intelligence. Its name offers little help in guessing the business. Its product descriptions are more revealing. Again and again, they return to the same problem: useful information trapped behind the boundaries of different systems.

Leave the data where it lives

MPI calls its underlying technology Information Spectrum. The company describes it as a way to aggregate and harmonize information from disparate databases, then make that information available for business intelligence and workflows. Its advertised database support includes Microsoft SQL Server, Oracle, MySQL, DB2 and Access. Mainframes and client-server applications sit inside the intended picture.

The distinctive promise is access without building an intermediate store of everything first. MPI describes real-time data virtualization “without the need of data warehousing or intermediate data storage”. In ordinary language, the goal is to bring answers together while leaving the underlying records in their original systems. Role-based rules govern access; triggers can pass control to other applications.

“without the need of data warehousing or intermediate data storage”

MPI’s description of Information Spectrum

That makes MPI an enterprise interoperability business as much as an invoicing business. The customer problem is recognizable: one department has a useful application, another has a different one, and the work crosses both. The appeal lies in making those applications cooperate. MPI’s stated expertise in collateral management, RFID and process improvement fits that focus on operational connections.

Three ways to get a bill paid

Global eIPP applies the technology to electronic invoice presentment and payment. MPI advertises automated reconciliation and approval, interactive dispute management and dynamic discount management, with cloud SaaS or in-house deployment. The intended users are billers, payers and bill aggregators. An invoice can arrive as usable information, be checked, encounter a dispute and move toward settlement within the proposed workflow.

The eBILIS name also appears in MPI’s public record. Current eBILIS literature is published under EBILIS, INC.; it provides a more detailed view of this invoicing approach without establishing that the two company names are legally interchangeable. Its three editions organize the problem around the relationship between the people sending bills and the people paying them.

Vega serves accounts receivable: present the seller’s invoices and return payment details. Lyra serves accounts payable: populate the buyer’s system and reconcile invoices against procurement, shipping and receiving information. Absolute combines the two sides for bill aggregation. The taxonomy is useful because a seller collecting from hundreds of buyers faces a different coordination problem from a buyer paying hundreds of suppliers.

The remittance details matter. Sending money and explaining what the money settles are separate tasks. eBILIS describes returning that explanation in the format the receiving business needs. Lyra also lets payers work through their own accounts payable applications. The practical attraction is less rekeying and fewer unfamiliar interfaces, rather than another destination employees must learn to visit.

The bank, the dealer and the seven-day clock

MPI’s published DealCOR scenario makes its thinking unusually concrete. The document describes a bank’s revolving seven-day credit product for a petroleum dealership chain. Purchase orders, credit availability, deposits, interest calculations and remittance information all have to line up. The proposed portal gives the bank, petroleum company and dealers views into the parts of that process relevant to them.

The document specifies a delivery target of less than three months after approval of a statement of work. Read that as a proposed deliverable, rather than a measured customer result. Its revealing detail is the connection between funding and a purchase order: the system is meant to tell the petroleum company when a dealer’s order has been funded. Information becomes a signal for action.

From MPI’s drawing board

A separate MetaPhase bank-merger diagram places different banking systems behind a shared teller interface. Oracle appears on one side; COBOL and a mainframe appear on the other. These are proposed application patterns, but they explain MPI’s market position better than a long industry list. Its interest is in the difficult space where existing systems must share a business process.

Copy the question before the software

The business model follows that enterprise setting. MPI offers software and services, while Global eIPP can run in the cloud or in-house. Current eBILIS materials additionally describe branding and co-branding options for banks and other providers. For a buyer, the relevant cost exercise includes application access, configuration, hosting, operational support and the work of changing invoice handling.

There is a useful exercise to copy: trace one invoice from creation through receiving checks, approval, payment and remittance. Include a disputed invoice. Mark every place someone copies information or waits for an answer. As an evaluation principle, source-connected software is most useful when those sources are accessible and the parties agree on what the records mean. Inaccessible applications or contradictory matching rules still need attention.

MPI’s proposition rewards that close inspection. An invoice can look like a document while behaving like a relay between departments, databases and banks. Follow the relay carefully, and the software question becomes specific: which handoff can disappear?