12.2 FeeTax Requirement Pattern


12.2 Fee/Tax Requirement Pattern

Basic Details

Related patterns:

Inter-system interface, inter-system interaction, extendability, configuration, calculation formula

Anticipated frequency:

From one to upwards of a dozen requirements. A commercial system with no fees or taxes specified is likely to be incomplete.

Pattern classifications:

None

Applicability

Use the fee/tax requirement pattern to specify any fee or tax the system must calculate, report on, or levy. This requirement pattern can also be used (with only slight variations) to specify a discount on an amount a party is charged.

Do not use the fee/tax requirement pattern for any fee or tax for which the system does not contain the information on which the fee is based (such as charges for software development work). Such fees can be described informally in a requirements specification but not as formal requirements the system must satisfy.

Discussion

Sales tax, annual subscriptions, postage and delivery charges, transaction fees, agent commissions: few serious commercial systems don't involve a fee or tax of some kind. Fees are the sole source of revenue for many businesses. Taxes are a necessary evil, but getting them wrong is potentially disastrous if a company has to pay for mistakes out of its own pocket. Taxation authorities are not renowned for their compassion and flexibility. So calculating and levying fees and taxes deserve to be treated seriously, starting with their requirements.

A fee is any amount that one party charges to another for providing some kind of service. Underlying fundamental amounts, such as the purchase price of an item being bought, are not fees. A tax is any amount a taxation authority charges to a party (while providing no service directly in return!). As far as system specifications and software are concerned, a tax behaves so much like a fee there's nothing to be gained by treating them separately. In this requirement pattern the term "fee" should be taken to include tax too, unless it is clearly not appropriate. Fee rate means either a fixed monetary amount or a percentage.

Include requirements for all fees and taxes levied on the business for which the system is responsible. Do this even if fees are managed, collected, and even calculated by some other system (such as an accounting system, a dedicated billing system, or a spreadsheet). This makes developers aware of the information needed to calculate the fees so that they can take steps to provide it. For each other system involved here, specify requirements for an inter-system interface to it and requirements for the information to be passed across it. They make clear the responsibilities of each system; without them, it's hard to apportion responsibility for any difficulty that results. (See the inter-system interface and inter-system interaction requirement patterns in Chapter 5, "Fundamental Requirement Patterns," for further details.) If no such external system is in place but you assume there will be or should be one, state your assumption explicitly-and work through the consequences.

image from book
Revenue Model

If a system has more than two or three fees and taxes-or if the financial workings of the business aren't self-evident, which means nearly all businesses-it's worth tackling financial flows in a more systematic manner than just writing requirements for each fee and tax you can think of. A diagram is the best way. Show each kind of party who can pay or receive money, and then show all the possible flows of money between them that the system cares about. (Don't worry about flows between third parties.) Here's an example:

image from book

It's hard to show relationships between flows (such as how the revenue from one order is shared among several parties), but that's a secondary matter. What's important is to capture all the flows, so that none are forgotten-though for simplicity it's usually best to omit corrections and adjustments. Observe that multiple boxes are shown for some of the parties; this signifies that there could be many of them. Sometimes it's worth going into more detail to show the main accounts into which money is placed. Diagrams like this can be surprisingly difficult to draw, which is a sign that you don't fully understand how the business works.

image from book

Sometimes fees are omitted from the requirements specification on the assumption that all the raw information is there so it'll be easy to add them later. But if it's easy, it'll be easy to specify now. If it's not easy to specify now, that's even more reason to do so. Until you specify a fee, you don't know how tricky it might be. Don't leave loose ends here: they might become very frayed indeed. And just because the system has the raw data at some point doesn't mean it stores it; and even if it does, it might not be in a form that's convenient for calculating the fee. The details could contain all sorts of little complexities, some of which might be discovered only during development, but the analyst should aim to pin down everything they can and leave nothing unresolved.

image from book
Accountants as Programmers

Finance departments responsible for levying fees and for paying taxes often use spreadsheets to juggle the requisite figures; spreadsheets are powerful for this purpose and provide flexibility to modify the results that's hard to match. But if the data provided to them is in an inconvenient form, spreadsheets of mind-boggling complexity can be the result, and accountants are remarkably adept at concocting them. This is very bad practice. If we look at such production spreadsheets as software (which they are), they are software built in the worst possible way: unspecified, unstructured, full of repetition, with changes untracked, undocumented, and untested (indeed, virtually untestable-and unauditable), and usable and modifiable only by the author. Often their very existence is known only to the person responsible, and the (considerable) expense of producing and tending them goes unseen.

Frankenstein spreadsheets are a sign that the data in the system that spawned them is inadequate and badly designed. The answer is to properly investigate the financial and accounting needs up front-and to bring them fully within the scope of the system. Spreadsheets might well play their part in the solution, but if properly planned they will be a lot simpler and their role will be clear. Reducing dependence on uncontrolled mammoth spreadsheets also makes auditing easier, which assists in compliance with financial regulations (such as SOX in the U.S.).

image from book

Content

The five key factors in any fee or tax are: how, on what, when, from whom, and to whom. A requirement for a fee or tax needs to convey the following information:

  1. Name What is this fee or tax called? Be clear, precise, and unambiguous.

  2. Basis The nature of the calculation (how). The most common bases are:

    1. Fixed monetary amount (for example, a flat $0.20).

    2. Percentage of some other monetary value (for example, five percent of the purchase price).

    3. Monetary amount per time period (for example, $0.50 per month).

    More complex kinds of calculation are possible, such as tiered or threshold rates. Tiered rates are divided into bands with a different rate applicable to each band (for example, $0.20 each for the first 20 Web pages viewed, $0.15 for each of the next 20, and $0.10 each thereafter). Threshold rates are similar, but just the rate belonging to the band into which the amount falls is used (for example, up to $100 shipping is 15 percent, between $100.01 and $200 it is 10 percent, $200.01 and over it is free). If you use such rates, explain exactly how they work.

    Cite fee rates as indicative only; make them configurable.

  3. Origin What is the thing that is being charged for (on what)? A fee is usually charged either on an event or over time. Typical events on which a fee is charged are:

    1. A transaction (for example, an order).

    2. An event in the life of a living entity (for example, the registering of a new customer).

    3. An action within the system (for example, the running of a report). It is useful (and in practice usually necessary) to record every action on which a fee is charged.

    Charging over time is typically applied to a living entity, either directly to its life (for example, an annual fee for the life of a credit card) or via a subsidiary living entity created just for this purpose (such as a customer's subscription to a magazine, which continues for as long as the customer pays the fee).

    When multiple different fees are applied on the same thing, make clear the order in which they are applied and take care to precisely identify the amount that each fee is calculated on. For example, is sales tax calculated on postage?

  4. Condition (if relevant) Is this fee always charged or only in certain circumstances? For example, a bank might charge for account statements only if the account is overdrawn or might charge sales tax only to domestic residents. Describe the conditions under which the fee applies.

  5. When levied Describe at what point the fee is charged to the payer-that is, when the liability to pay is incurred. This is either when they are actually debited or when they are sent the bill and asked to pay. Note that fee amounts are not necessarily credited to the receiver immediately the payer pays (for example, taxes collected might be paid quarterly).

  6. Payer Who pays the fee (from whom)? In most cases the payer and/or receiver are obvious and can be omitted. But first ask yourself where the money is going from and to. If it's not clear or if the answer is "It depends," nail it down and state the answer explicitly.

  7. Receiver Who receives the fee (to whom)? In some cases, a fee might be shared among more than one receiver-for example, when part of a fee is paid as commission to an agent. Situations like this can be treated as two fees, one based on the amount of the other.

  8. Fee rate determinants What determines what the fee rate is? Often the same fee rate is always used (though even then it might change periodically). But other factors could come into play, such as where the payer or receiver resides (geographically-such as shipping charges depending on country), or who the payer and/or receiver are (that is, special rates for a specific party or specific combination of parties), or the currency of the amount to which the fee applies (it might look slicker to define a nice round number for each currency, rather than convert a single value into another currency), or the type of a transaction.

    If this isn't stated, developers should assume the rate to be a systemwide configurable value (that is, the same rate is used in every case).

  9. The system's responsibility How much of the work does the system need to do? The main possibilities:

    1. Calculate the fee and automatically debit the payer and/or credit the receiver. Debiting means either taking money directly (such as via their credit card) or debiting an account that represents real money (such as an account or "electronic purse" we maintain on their behalf).

    2. Calculate and automatically inform the payer and/or the receiver (in effect, send them an invoice).

    3. Calculate and pass the details on to another system (such as an accounting or billing system or export for use by a spreadsheet).

    4. Make sure the raw information is present, ready to be passed on to another system.

  10. Reference If the fee is defined in more detail elsewhere, state where this further information can be found. This is most applicable to taxes, for which truckloads of supporting material are usually available.

This list looks more daunting than it is in practice. However, it does explain only the basics of the fee. Many-perhaps most-fees involve various special cases and complications. Each of these should be specified in an extra requirement-first, so that they attract the attention they deserve, and second, because the fee's main requirement is likely to be large enough already.

A discount (such as 10 percent off) can be specified in a similar manner to a fee: it is, in effect, a negative fee based on another monetary amount. Use the preceding list as a guide for the information to include in a requirement for a discount, but identify what the discount is based upon, and note that the payer and receiver can be omitted.

Template(s)

Open table as spreadsheet

Summary

Definition

«Fee/tax name» fee/tax

The system shall calculate a «Fee/tax name» fee/tax as a «Basis» on «Origin» provided that «Condition». It is paid by «Payer» to «Receiver» «When levied». The [fee]/[tax] rate shall be determined by «Fee/tax rate determinants».

The system is responsible for «System responsibility».

Source: «Reference».

Example(s)

Open table as spreadsheet

Summary

Definition

Transaction fee

The system shall calculate and automatically levy a fee on each customer transaction of a type for which a transaction fee is defined as payable. The fee rate shall be defined for each transaction type.

Sales commission

The system shall calculate the sales commission payable to each agent for sales they make. It is calculated as a percentage of the value of each sale (excluding postage/delivery and insurance amounts).

Sales commission is paid by the system operator to agents. The system shall not automatically generate payments to agents.

Report fee

It shall be possible to charge for each report delivered to an external party (for example, to charge an agent for each monthly statement). The fee rate shall be defined for each type of report.

Device rental

The system shall calculate and automatically levy the rental fee to be paid by each customer for the devices they have rented. It shall be charged monthly, at the end of the month. It is calculated as a fixed amount per month for each device the customer had installed during the month.

The per-month fee amount can vary from one customer to another.

Device installation fee

There shall be a fee payable to the rental service operator for each device installed by them at a customer site. It shall be charged monthly, at the end of the last but one working day of the month. It shall be a configurable fixed amount (intended to cover travel) plus an amount per hour. It is the responsibility of the system to calculate the number of device installation visits and the time spent on each one.

The minimum chargeable time for an installation is one hour.

It shall be possible to specify different fee amounts for each type of device.

General sales tax

It shall be possible to calculate and levy General Sales Tax (GST) on all amounts liable to it, including fees. GST is to be calculated as a fixed percentage (currently 10%) of the total value of any order from a domestic customer.

The GST rate shall be configurable. Any change shall be effective from a nominated date. A complete history of old rates shall be retained indefinitely.

Extra Requirements

The main requirement for a fee gives a good idea of what the fee is all about, but it is rarely enough by itself. Here are some common extra topics to consider, the first five of which are dealt with in more detail in their own subsections:

  1. More detail, to specify the fee more precisely. What else must be said to be able to calculate the fee correctly and unambiguously? For example, it might be necessary to introduce it at a precise date and time, especially if it's a new tax being introduced.

  2. Special cases and complications. Are there any oddities you need to worry about? If there are, you mustn't simply ignore them.

  3. Consolidation. Some fees-especially some types of taxes-are not just a lot of individual amounts lumped together: they involve further processing on the consolidated amounts.

  4. Manual intervention. Do we need someone to review and approve a fee before levying it, or to approve a tax amount before reporting it to the relevant authority? What about providing the ability to waive a fee if appropriate? Functions to manually apply a fee, or to make a manual adjustment, are always useful-unless you can guarantee the system caters for every conceivable eventuality and will never make a mistake (which you can't). They're a kind of insurance policy.

  5. Justify fee amount. What if a customer complains a fee is too high, and you can't tell why? Might someone want to be able to look at a fee amount and ask where it came from? It'd be useful to understand how was it calculated without a major investigation or having to call upon a developer.

  6. Tracking unpaid fees. If the system asks the payer to pay a fee but doesn't debit them directly, how do we track whether they've paid? Is it the system's responsibility? If so, what must it do? (Consider requirements for producing statements, a function to record payments received, and internal reporting.) If not, who or what system is responsible? If it's an external system, have we defined an interface to it? If there are no requirements on our system, say so-to stop anyone wondering if we've forgotten them.

  7. Fee rate changes. Fee rates are likely to change, and any good system can take them in its stride. We want a fee rate change to take effect at a precise time, and we need to know what the fee rate was at any moment in time. This topic is covered in detail in the configuration requirement pattern in Chapter 7, "Data Entity Requirement Patterns" (which is directly relevant because fee rates are part of the system's configuration).

  8. Eliminate fee. Do we need to be able to stop levying this fee at some point in the future, without modifying the software?

  9. Extendability. From time to time organizations change how they charge fees, add new ones, and replace one with another. Governments fiddle with tax regimes when they see fit. So it's wise to demand that this area be built flexibly so that future changes involve as little pain as possible-especially if you're building a system to run in multiple countries or a product to be used by various organizations. See the extendability requirement pattern in Chapter 10, "Flexibility Requirement Patterns," for further details.

Many of these extra requirements can be written to apply to only one type of fee or to apply to all types, or anything in between, as necessary.

More Detail

A quick description of how to calculate a fee often contains ambiguities; it can raise more questions than it answers. Write extra requirements to resolve these ambiguities. (Most of this subsection relates only to fees that must be calculated, rather than to fixed fee amounts, although one or two points apply to the latter.)

First comes the nitty-gritty of the calculation. To how many decimal places should the fee rate be held? To how many decimal places should the fee amount be calculated? Should any rounding be applied to the calculated fee amount, and if so, how? These might seem like trivial questions, but tax regulations are often definite and intolerant about such things. It's also important to adhere to stated definitions of fees if they have been agreed to and published to customers or if we're building a system that must be consistent with some other system.

Fees levied over time are particularly fiddly. Resolve the following matters:

  1. What does the time period really mean? For any time period of a month or more there are at least two answers, which we can call calendar or lapsed. A calendar month (or quarter or year) is exactly as per the calendar: paying for January means up to the 31st January, so if we start on 14th January we don't pay the full month. A lapsed month is an actual month from the start: from 14th January to 14th February.

    For time periods measured in quarters and years, make clear what you mean. Are quarters three-month periods starting on 1st January? Are years calendar years or financial years? If financial years, on what date do they start? Might this vary, if the system will be used in different countries?

    Be aware of minor anomalies with lapsed time periods. Does a lapsed month from the 31st January end on 28th February? Then might a customer who pays for another month feel short-changed when told it ends on 28th March? The problem is that two months doesn't always equal one month plus one month.

  2. How do we charge for a partial time period? For half a month, do we charge for that fraction of a month, for a full month, or nothing at all?

  3. When do we start charging the fee? When do we stop? What events constitute the start and end?

Last, do we have any multi-currency issues to worry about? Can the amounts on which a fee is calculated be in different currencies? If so, we must either convert the fee amount into that currency (resulting in a funny-looking fee amount) or define the fee amount in each currency we support (which means a lower fee in some currencies than others, if we use nice round numbers).

Here are a few representative extra requirements for some of the details just described:

Open table as spreadsheet

Summary

Definition

Fee monetary amounts to at least 4 decimal places

Any fee that is specified as a monetary amount shall be definable to at least 4 decimal places of cents (for example $0.0025).

Fee percentages to at least 2 decimal places

Any fee that is specified as a percentage shall be definable to at least 2 decimal places (for example 0.05%).

Device rental for partial month

If a device is rented only for part of a month, a proportion of the monthly rental fee shall be charged according to the number of days in the month during which the device was installed.

For example, for a device activated on 9th May, (31 - 9 + 1)/31-or 23/31-of the normal monthly device rental fee will be charged for May. (See the requirements that follow on start and end of device rental.)

Start of device rental

Device rental shall start at the moment the device is installed at the customer's site, for the purpose of device rental fees.

End of device rental

Device rental shall end at the moment the device is removed from the customer's site, for the purpose of device rental fees.

Special Cases and Complications

Don't assume that working out a basic fee amount is the end of the story. Here are a few situations you might encounter that affect the result:

  1. Minimum and maximum fees. Don't bill for silly amounts-either ridiculously low or high. Stories keep on popping up about computer systems chasing people for $0.01. Don't be guilty of perpetrating professional embarrassments like this. More sophistication can be added by comparing a fee amount with previous amounts charged to the same payer, or by asking for suspiciously large (or small) amounts to be manually approved before they are charged. The latter is likely to need its own threshold values defined.

  2. Fee-free period, such as first month free.

  3. Odd fee periods. Some organizations are forced to calculate periodic fees according to odd periods, because manual processes take several days at the end of the month. It's unfortunate that this happens, but when it does, all systems that provide billing-related information are forced to adhere to it. (Also bear in mind that this situation might improve in the future, which means that the system might be expected to switch to a more natural way of working. It's easy for such a switch to go wrong.)

  4. Rates that vary over time, such as different rates at off-peak or busy times, or an annual subscription that becomes cheaper each year to reward loyal customers.

This section mentions things that are relatively common. Always properly investigate the complexities that apply in your own situation. Fees are invariably more complex than they appear, and failing to deal with the complexities can result in incorrectly calculated fees.

Here are a few example requirements for some of these things:

Open table as spreadsheet

Summary

Definition

Free period for fee over time

For each fee charged over time, it shall be possible to specify an initial period for which no fee is payable.

For example, an annual fee might be charged but the first year could be free.

Fee rate varies according to time

It shall be possible for different fee rates to be applied depending on the time of day and/or day of the week.

The intent of this requirement is to facilitate peak and off-peak fees.

Fee over time changes over time

For each fee charged over time, it shall be possible to specify that a different fee rate be used after different lengths of time.

For example, an annual fee might be $15 in the first year, $10 in the second year, and $5 per annum thereafter.

Consolidation

For some fees and taxes, the amount that's actually charged isn't just a matter of adding up amounts from the things on which it's charged: extra processing might be needed. Minimum or maximum fee amounts might apply to the total, not just individual fee amounts. Investigate what's needed. Here's an example:

Open table as spreadsheet

Summary

Definition

Netting of sales tax

Where one organization passes on to another organization part of an amount received (such as a fee), sales tax shall be payable only on the net of the two amounts.

For example, if the system operator receives $2.00 from a customer and pays $0.50 of that to an agent, the system operator pays sales tax only on the $1.50 difference.

Manual Intervention

Leaving a system to calculate and levy fees all by itself can be a risky business, given how sensitive people and organizations are about paying money and how many questionable situations can occur. Useful features for which to consider writing requirements can be divided into those that prevent mistakes and those that correct them.

Preventing mistakes means allowing someone to review what the system proposes to charge before it is allowed to go ahead. Review is useful only if something can be done about those the reviewer's not happy with-which means both the ability to approve the fee and to make an adjustment to it (including to waive the fee altogether). Manual review is practical only if the number of fees to be approved is of manageable proportions; if there are too many, you can still consider reviewing large amounts and letting the rest through automatically.

Correcting a mistake involves the ability to enter a fee amount in order to credit or debit the affected party. It helps if you can enter an explanation to make the adjustment's purpose clear. Here are a couple of simple examples:

Open table as spreadsheet

Summary

Definition

Manual fee entry

It shall be possible for a user to enter details for a one-off fee.

Manual fee adjustment

It shall be possible for a user to make a manual adjustment to an existing fee amount that has been levied.

Justify Fee Amount

Computer systems are good at making masses of calculations, but they're awful at explaining what they did and why. Unless you expressly ask for accountability from software, you are most definitely not going to get it-and if you do ask, you'll only get it with a fight, because it's very difficult to implement properly. Even a spreadsheet will tell you only the formula it used, not where its data came from. Still, justification of how a fee was calculated can be valuable and a system feature worth paying for. If a taxation authority questions how you arrived at your tax amount and you can't tell them, you could find yourself in trouble.

Here's an example that's all-embracing (and, as a result, to be used only if you appreciate the consequences):

Open table as spreadsheet

Summary

Definition

Justify fee amount

For each fee amount calculated, it shall be possible to obtain justification of how the amount came about. For example, when a fee amount is displayed to a user, that user shall be able to ask to see justification of that amount. Justification shall be taken to mean display of the formula used plus an explanation of the origin of each value supplied to it.

Considerations for Development

If a system involves several types of fees and taxes and might need to accommodate more in future, it's worth building this area in an extendable manner. This is especially true if you're building a product that is liable to be used in different countries, with different tax regimes.

Considerations for Testing

When reviewing requirements, check each fee requirement for precision: does it make clear what's meant to happen in all circumstances?

Testing fees can be divided into two parts. First, test that each fee is charged when it should, and only then. Second, test that each fee amount is calculated correctly (as per the calculation formula requirement pattern in Chapter 6, "Information Requirement Patterns"). If there are multiple types of fees, both parts must test that different fees interact as they should-that is, that you're not charging fees on fees (or taxes on taxes).

View fees from the perspective of each of the interested parties: the payer, the receiver (especially if it's a government taxation agency), a user involved in administering the fee, and an auditor. Is each party given all the information they might reasonably expect?

Test all manual actions involved in levying a tax, and check that they are practical. If unusual fee amounts must be approved, is the approval action efficient? Does it tell the user everything they need to decide whether to approve it?




Microsoft Press - Software Requirement Patterns
Software Requirement Patterns (Best Practices)
ISBN: 0735623988
EAN: 2147483647
Year: 2007
Pages: 110

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net