1100030	Brnch Dep Merch Card Draft	0.1000	R
1100040	Brnch Coin and/or Curr OrdMan	0.1000	R
1100041	Brnch Coin and/or Curr OrdStnd	0.6947	R
1100042	Brnch Coin and/or Curr OrdSpec	0.1000	R
1100043	Brnch Furn CoinLoose	0.1000	R
1100044	Brnch Furn CoinRolled	0.0700	R
1100045	Brnch Furn CoinHalf Box	0.1000	R

At[0026]

step

112, the data processing system finds the tax rate corresponding to a particular service code of the financial transaction. An “excluding tax” amount can then be computed as the difference between the revenue and the VAT. The service codes and the mapping rules allow the company to breakdown individual supplies and acquisitions for their respective applicable individual VAT treatments. For example, the data processing system of one embodiment uses the rate table named by the parameter-variable AP-REVENUE-TAX-RATES-TABLE to calculate the “excluding tax” amount. Atstep114, the data processing system stores the date-effective tax rate in the data processing system alongside the revenue. Of course, the data processing system could store either the date-effective tax rate percentage, or the calculation of the date-effective tax amount. The data processing system then proceeds to “Process for Cost Tax”step116.

At[0027]

step

118, to compute the applicable cost tax credits, if the billing plan is in the “Other” category (step118), cost tax table “TAXC” is associated atstep122. Alternatively, if the billing plan is in the “SERV” category, cost Tax Table “TAXS” is associated at step120 (i.e., a formula approach can be used with service revenue). In either case, atstep124, the applicable tax credits for the financial transaction are computed from the applicable tax table using the service codes. The date-effective tax rate is stored in the billing record alongside the cost. A second “excluding tax” amount may be calculated, equaling the total cost less the applicable cost tax credits. For example, the data processing system may calculate the second “excluding tax” amount using the tax tables found in the parameter-variables AP-SERV-COST-TAX-RATES-TABLE, when the billing plan is of the “SERV” category, and AP-OTHER-COST-TAX-RATES-TABLE, when the billing plan is in the “Other” category.

The data processing system, in[0028]

step

128, can then manipulate the stored data in the billing record relating to the revenue, the revenue tax, the costs, and the cost taxes, so that input credits, taxes owed, taxes to be credited are determined. Further, a profit amount can be calculated for each transaction as the difference between the “excluding tax” amounts. Alternatively, the “excluding tax” profit can be computed by applying the revenue tax and the acquisition tax credits to a pre-tax profit. The data processing system can itemize in a statement or a report a list of all services, taxes assessed on the products, and acquisition tax credits to be applied, and the net tax owed to the government, and any other presentation of the data. This data may then be displayed by a user interface (e.g., a computer screen) or reported on an itemized statement generated internally, or generated for a customer or a reporting authority (e.g., an electronic account statement).

In this manner a company can accurately calculate the taxes associated with each service being rendered in the appropriate tax jurisdiction, and the input tax credits and reduced input tax credits that can be applied to each service in each instance. Each component of the customer transaction is thus properly accorded the applicable tax treatment, i.e., whether the components of the transaction is taxable, or tax-exempt in each applicable tax jurisdiction. Costs also are properly treated for tax credits according to whether the costs are internal, out-sourced or imported, and whether that service is eligible for reduced input tax credit. Acquisition activities can likewise be mapped to all supply activities, so that standard unit costs are allocated to the acquisition activities. The input tax credits and reduced input tax credits are calculated based on the tax status of each acquisition activity's related supply activity.[0029]

Using service codes and product rules in this manner enables an accurate and comprehensive analysis of each financial transaction, providing maximum flexibility in treating transactions that are taxed in different manners, classes, and rates individually. For instance, a company may classify every financial transaction service by service, and evaluate the cost separately from the revenue.[0030]

Alternatively, rather than computing taxes on the component basis, the components of a transaction can be aggregated, and the applicable taxes computed on the aggregated total. In fact, in one embodiment, the tax tables are applied to aggregated transactions of an account, transactions of a group of accounts of the same customer, transactions of a legal entity or transactions occurring within a given tax jurisdiction.[0031]

According to another aspect of the present invention, the data processing method and system convert currencies from different transactions into a common currency for each account or customer. The financial institution or its customers can therefore analyze transactions and accounts in one or more common currencies, while at the same time conduct the transactions in the different currencies that are required. Viewed another way, according to the present invention, a company can manage its business as if it uses a single or a small number of “global” currencies, while actually conducting business in a large number of currencies. A company can further price multi-currency financial transactions and CAA accounts in a common currency regardless of the currencies used in the transactions or handled in the accounts.[0032]

The multi-currency support analysis can operate in conjunction with the financial service tax support analysis described above to provide a system for global pricing and tax-determination for transactions occurring in various places of the world.[0033]

The multi-currency support analysis is applied individually to each financial transaction, which is stored in the data processing system in the currency the transaction was carried out. Like the tax support analysis described above, the data processing system links a transaction or entity to a currency exchange rate table using product rules, mapping rules and service codes. A currency exchange rate table contains rate information for converting one or more currencies to a second or common currency.[0034]

FIG. 2 is a flow chart of an[0035]

exemplary method

200 for a multi-currency support analysis according to one embodiment of the present invention. Beginning atstep202, the data processing system identifies and validates (step204) each financial transaction that has occurred during a billing cycle to perform a multi-currency analysis. Atstep206, the transaction amount is stored in its native currency (i.e., the currency in which the transaction is carried out). For each account involved in the financial transaction, atstep208, the data processing system converts (if necessary) the applicable amount of the transaction in the currency in which the account is kept, and stores, atstep210, the transaction under “category M” (i.e., the account's currency). The conversions are made using exchange rate tables, which are associated using product rules in the manner similar to that discussed above with respect to associating a transaction with applicable tax tables. In one application, the conversion calculations of the currency exchange rate tables adhere to a standard specified for the Euro currency. Under that standard, for example, exchange rates are specified to six significant figures. A conversion between currencies A and B via a common currency C involves dividing the amount in currency A by a first exchange rate to arrive at an equivalent amount under common currency C, and then multiplying the amount in currency C by a second exchange rate to arrive at the equivalent amount under currency B.

Next, at[0036]

step

212, the transaction is converted from its native currency into a common currency (e.g., U.S. dollars or Euros), and stored atstep214 under “category N” (i.e., in the common currency). Using this common currency, the customer (i.e., the account holder) can view all the accounts in a single “global” currency and at the same time keep each account in its native currency. In one embodiment, the data processing system of the present invention uses an exchange rate table specified in the parameter-variable AP-COMMON-CURRENCY-CODE.

Of course, the data processing system updates the exchange rate tables on an ongoing basis. Update can be achieved by accesses over the Internet, from an update service, or from other data sources. Because exchange rates are constantly varying, transaction amounts, account balances, and pre-priced revenues are time-sensitive. In one example, the exchange rate tables may be updated every 15 to 60 minutes, depending on the accuracy desired. The new exchange rates are stored with a Min-Tran threshold tag that keeps track of the elapsed time since the last update on any particular day.[0037]

In some embodiments the exchange rates can be stored as multipliers with a method “R” and schema “RATE”. For example, a Rate Table to convert the Euro to various currency equivalents can be provided as follows:[0038]



	Entity Name:	EUR
	Product:	CURX
	Schema:	RATE
	Valid From Date:	Jan. 13, 2000
	Minimum:	1315

ATS	AustriaSchilling	12.0919	R
AUD	AustraliaDollar	1.5753	R
BEF	BelgiumFrancs	42.0168	R
BRL	BrazilReal	1.66611	R
CAD	CanadaDollar	1.39938	R
GBP	UKPound	.689275	R
USD	USDollar	.951475	R

Using the exchange rate table above, for example, 43.15 British Pounds is converted to its Euro equivalent by the data processing system first locating the currency exchange rate table EURO above for product CURX, which is tagged with a valid-from-date and time (min-tran-count) tag that is the closest and hence, most appropriate, to the date and time required (e.g., the timestamp that equals or immediately precedes the effective accounting timestamp of the transaction). From this exchange rate table, the data processing system looks up the British Pound “GBP” (i.e., the Euro-to-GBP-rate). 43.15 GBP is then simply divided by the Euro-to-GBP-rate, giving 43.15/.689275=62.60 Euros to two decimal places.[0039]

To convert between two currencies that are not one of the selected common currencies, a two-step process can be used. In the first step, the transaction amount in the first currency is converted into the common currency, and then, in the second step, the amount in the common currency is converted into the second currency. For example, if it is desired to convert 2,500.00 Canadian Dollars to Brazilian Reals, the data processing system uses the procedure described above to convert the 2,500 Canadian dollars into 1,786.505452 Euros. (Here, the Euro equivalent is rounded to six decimal places for added precision even though, under the Euro standard, only four decimal places are required for interim results.) The system then looks up the BRL service within this set of EUR exchange rates (i.e., the Euro-to-BRL-rate), to obtain 1,786.505452×1.666110=2,976.51 BRL (rounded to two decimal places).[0040]

FIG. 3 shows a flow chart of an[0041]

exemplary method

300 for multi-currency support pricing of a transaction, according to one embodiment of the present invention. As shown in FIG. 3,method300 is applied from a CAA main account. A CAA is a group of related accounts consisting of a main account linked to one or more subordinate accounts. Atstep304, the data processing system determines the CAA's “billing category”, which is either category N (common currency) or M (the selected currency for the account). In one application, where a CAA contains mixed currencies (e.g., account1 is GBP, account2 is USD, account3 is USD, and account4 is EUR), billing category N (common currency) is used to ensure a consistent currency is applied to the entire CAA.

When the CAA's billing category is category N, the data processing system obtains category N activity (or services) for the CAA in[0042]

step

320. Atstep322, the related unit price records for the services rendered are obtained, and instep314, prices are applied to the activity. Thus, a CAA with a common currency is priced using the common currency. Alternatively, when the CAA's billing category is category M, the data processing system obtains each account's currency code within the CAA instep306. In one embodiment the account currency code is stored as an attribute on the account record. The data processing system then determines if the CAA is a mixed currency CAA instep308.

When the CAA is a mixed currency CAA, the data processing system obtains category N activity for the CAA in[0043]

step

310. To price a mixed currency CAA, pricing is established using the common currency. Thus, the monetary amounts of the CAA (e.g., account balances, transaction amounts, pre-priced revenue amounts) are converted to the common currency (i.e., category N).Step310, likestep320, obtains category N activity for the CAA. Atstep312, the data processing system obtains default unit price and cost tables for the common currency, and then applies the appropriate prices to the activity atstep314.

When the CAA is not a mixed currency CAA, at[0044]

step

316, the data processing system obtains category M activity for the CAA. Atstep318, the data processing system obtains related unit price records for the services rendered and then applies, atstep314, the related unit prices thus obtained to the activity.

In some embodiments, although the pricing and costing functions are performed at the CAA level, total revenue and cost for each service used can be apportioned back to an individual account or transaction, if desired. For example, one may determine the profitability of a transaction by executing the pricing and costing against the CAA(s) of the debit and credit accounts, and then apportion the pricing and costing thus obtained back to the individual accounts according to an appropriate rule.[0045]

Therefore, the present invention provides a method and a system for conducting a financial transaction in any currency while, using the multi-jurisdictional tax support and multi-currency pricing analysis described above, allowing both pricing and taxes related to the transaction to be computed for any desired currency. For example, a company located in the United States, operating on US Dollars basis, can determine the pricing and the applicable taxes for a subsidiary Canadian corporation, operating on the basis of Canadian dollars, for a financial transaction that took place in Belgium Francs. The subsidiary Canadian corporation can view the entire transaction, prices, and tax calculations in Canadian Dollars, while the US parent can view the same transaction in U.S. Dollars.[0046]

The above detailed description illustrates specific embodiments of the present invention and is not intended to be limiting. Numerous modifications and variations within the scope of the present invention are possible. For example, numerous combinations of the tax rate support method and system can be combined in various ways with the multi-currency support analysis and pricing method and system. Accordingly, the present invention is defined by the appended claims.[0047]