Fund Transaction Calculator: Rupees, Units and Load

A fund transaction calculator takes one instruction and pulls it apart. Given the figures from the holder's own documents, the sums, the unit count, each value per unit and a load rate, it returns the units allotted or cancelled, the rupees that actually move, the deduction on both of the bases it can be quoted on, and the fraction of a rupee that rounding leaves behind. The calculator settles nothing about which day's value attached.

Underneath that instrument sits a single division and a single multiplication. Everything a fund transaction does to a holder's money is one of those two run in one of two directions, and what people get wrong is not the arithmetic. The difficulty is that a value per unitWhat the scheme holds less what it owes, divided by the units in issue. almost never divides a round sum of rupees into a round number of units, so a remainder appears, gets rounded, and quietly moves the answer by a fraction of a rupee that nobody prints. The calculator prints that fraction.

One scheme supplies every default. Girnar Asset Management Limited runs the Girnar Large Cap Equity Fund, an open ended equity scheme carrying net assets of Rs 4,200 crore against 120.00 crore units in issue. Divide the first by the second and one unit is worth Rs 35.00 exactly. The tool starts there, and every box can be overwritten immediately. Kalyani Bhagat manages the portfolio and Sohail Merchant heads operations. The load rate the tool assumes is a teaching figure, chosen to make the arithmetic visible.

Three things are covered separately and are assumed here: what a unit and a value per unit are, what a subscription and a redemption do to a holding, and what an exit load is and that it bites on a redemption rather than on a purchase.

What does this fund transaction calculator actually work out?

The calculator takes one transaction and returns its parts: how many units moved, how many rupees moved, what came off in between, and what was left over when the unit count was written down. Everything it does is arithmetic that could be done on paper, and that is the point. The final figure is the one part of a fund transaction almost nobody disputes; the arguments happen in the middle.

So every intermediate figure is on screen at once: the division before rounding and after it, the redemption valueWhat cancelled units come to before anything is taken off. before the deduction and the proceedsWhat actually reaches the holder once every deduction has been taken off. after it, the deduction quoted on both of the bases it can honestly be quoted on, and the leftover fraction of a rupee printed rather than swallowed.

The instrument holds every rupee as a whole number of sub units rather than as a decimal, so the half paisa in its output is genuinely there rather than an artefact of the machine. Hide a residueMoney left over once a unit count is cut off at a fixed number of decimals. and it is not removed; it is merely arranged to turn up later looking like a fault.

How does money turn into units, and units back into money?

Rupees become units by division. Units become rupees by multiplication. Both operations turn on one figure in the middle, the value per unit. The value per unit is the exchange rate between the two things being counted, and the only figure in the transaction that neither the holder nor the scheme's registrar chose on the day.

A wholesale grain market works the same way. A buyer walks up with Rs 1,00,000/-, the day's rate is Rs 35.00 a kilo, and leaves with 2,857.143 kilos. Carrying those kilos back next morning at the same rate should buy back the same money. Division and multiplication by one value per unit are a single relationship read from either end, and a reader who can only run it in the buying direction will misread every redemption they look at. The trap is not the multiplication but the rounded count: the trip back does not land where the trip out started.

One thing happens before that division, and it is where a second common misreading lives. The sum divided is not always the sum that left the bank. Where anything was taken off before units were allotted, the units are worked out on what remained. With Rs 200.00 in the second box of the instrument, the sum handed over stays at Rs 1,00,000.00 while the units allotted fall from 2,857.143 to 2,851.429. The money did not move. The count did, by 5.714 units.

Why is the unit count written to three decimals, and what does that leave behind?

Because the division rarely ends. Rs 1,00,000.00 divided by Rs 35.00 is 2,857.142857 with the digits running on, so somebody has to decide where to stop writing. The Girnar Large Cap Equity Fund stops at the third decimal, a convention the scheme sets for itself rather than a requirement imposed from outside. Stopping there rounds the count up to 2,857.143, and that step is worth exactly one seven thousandth of a unit.

Multiply that step back into money. One seven thousandth of a unit at Rs 35.00 is Rs 0.005/-, half a paisa, and that is the entire residue. The holder handed over Rs 1,00,000.00 and the register shows units worth Rs 1,00,000.005/-. Nobody was given half a paisa and nobody was charged one. One figure was written to three decimals and the other to two, so the money and the record cannot agree to the last decimal.

Half of the last recorded decimal multiplied by the value per unit bounds the residue, and at Rs 35.00 a unit that bound is Rs 0.0175 whatever the starting sum. The residue does not grow with the transaction. A Rs 1,000/- purchase can leave a residue as large as a Rs 1,00,00,000/- purchase can. Rounding to three decimals is a fixed width tolerance in units and converts to a fixed width tolerance in rupees. The instrument prints that bound on the row under the residue, and prints both in rupees: as a percentage the residue would look like it was vanishing, and in rupees it plainly is not.

Rs 35,000.00 at Rs 35.00 gives exactly 1,000.000 units and the division ends. A dot would claim a tiny residue where there is none at all, so the second point on that chart is drawn as an empty outline. The tool does the same in words, reporting no residue on this setting rather than a row of zeros that reads like a rounded figure.

What does a load do to the answer, and what is it measured against?

Whatever a load is charged at, the quantity it bites on is the redemption value, so it lands after the multiplication and before any money leaves. Cancel 2,857.143 units at Rs 35.00 and the redemption value is Rs 1,00,000.005/-. Apply the 1.00 per cent assumed here for the Girnar Large Cap Equity Fund's exit loadA charge the scheme applies to units redeemed within a period it sets for itself in its own documents. and Rs 1,000.00005/- comes off, leaving Rs 99,000.00495/-, both carrying more than two decimals and printed that way on purpose.

Now the part that gets misread. The same rupees can be quoted as two different percentages, and both quotations are correct. Against the redemption value the deduction is 1.0000 per cent, the baseThe quantity a percentage is measured against. it was struck on. Against what reached the holder it is Rs 1,000.00005/- out of Rs 99,000.00495/-, exactly one hundred ninety ninths of a per cent, or 1.0101 per cent. The same deduction is 1.0000 per cent and 1.0101 per cent at the same moment, and which is right depends on which base the person quoting it had in mind.

Neither figure is a trick. The first gives what the scheme took as a share of what it held for the holder; the second gives what the charge cost as a share of what the holder can spend. A percentage quoted without its base cannot be checked, compared with another scheme's figure, or argued with. The tool prints both side by side, permanently. Fixing the commonest misreading of a charge in this subject needs no arithmetic, only the habit of naming the base out loud.

Why does asking for a fixed sum need more units than asking for a fixed unit count?

Because they are not the same request. Ask by unitsA request naming the units to cancel, so the money is whatever falls out. and the units are fixed; whatever money survives the deduction is what arrives. Ask by amountA request naming the sum wanted, so the units are whatever reaches it. and the money is fixed; whatever units it takes to reach that money after the deduction is what gets cancelled. One of those two quantities is nailed down and the other is free, and which is which flips between the two requests.

Both are worked at Rs 35.00 a unit with the 1.00 per cent assumed here. By units: cancel 1,000.000 units, the redemption value is Rs 35,000.00, the load takes Rs 350.00, and Rs 34,650.00 reaches the holder. By amount: the holder wants Rs 35,000.00 in hand, so the registrar has to solve for the unit count that survives the deduction. The unit count is Rs 35,000.00 divided by the product of Rs 35.00 and 0.99, or Rs 35,000.00 over Rs 34.65. Written to three decimals, that count is 1,010.101 units.

Two requests that both mention Rs 35,000.00 and both mention a thousand units produce unit counts 10.101 apart. The gap is not a rounding artefact but the load itself, counted in units instead of in rupees. Almost nobody works that out by hand, which is why the tool computes both cases at once. A household drawing a fixed sum every month is running the second case whether it knows it or not, and slightly more units leave the holding each month than the arithmetic without a load would suggest.

Which two operators can disagree by a whole paisa without either being wrong?

Two people with the same instruction, the same value per unit and the same load rate can produce two answers a paisa apart, and neither has made a mistake. The only thing they did differently was the order they rounded in, and nothing in the arithmetic tells them which order to use.

Follow both. The redemption value is Rs 1,00,000.005/- and the assumed load takes 1.00 per cent of it, or Rs 1,000.00005/- exactly. The first operator subtracts that exact figure and gets Rs 99,000.00495/-, then rounds to the paisa and writes Rs 99,000.00/-. A deduction is a rupee amount, and rupee amounts are written to the paisa. The second operator rounds the deduction first, and the deduction becomes Rs 1,000.00/-. Subtract that from Rs 1,00,000.005/- and the answer is Rs 99,000.005/-, exactly halfway between two paise. Rounding half up gives Rs 99,000.01/-.

One paisa apart, from the same three inputs, with no error anywhere in either calculation. The order the registrar uses is the scheme's own operating convention, and the tool shows both routes permanently. The size of the disagreement is the useful reading, and a single paisa points to rounding order rather than to a fault.

Does the forward check on the reverse solve actually check anything?

Partly, and it is worth being precise about which part. The tool solves for the units a fixed sum in hand requires, then runs those units forward to see whether the money comes back. Running the solve forward is the same expression rearranged, so its agreement is forced by algebra rather than earned by evidence, and no arrangement of one equation can corroborate itself. Divide where the code should have multiplied and the forward run compensates exactly, landing on the target anyway.

The rounding is what survives. The solve produces 1,010.101010 and the count is written to three decimals as 1,010.101, and from that moment the forward run is working on a different number from the one the solve produced. Multiply 1,010.101 by Rs 35.00 and the redemption value is Rs 35,353.535/-. Take the assumed 1.00 per cent, Rs 353.53535/-, and Rs 34,999.99965/- reaches the holder. The proceeds fall Rs 0.00035/- short of the Rs 35,000.00 asked for, and round to Rs 35,000.00/- to the paisa without ever having been Rs 35,000.00 exactly.

The shortfall is the only part of that check able to come out either way, and the tool prints the shortfall rather than the agreement. The habit has a long reach: when two routes agree, ask whether they could ever have disagreed. If they could not, the agreement is a restatement. Multiplication tests a rounded output that came out of a division, and a wrong rounding step shows up in the test. The cross multiplication the tool runs against its own unit counts is therefore a genuine check.

What has this calculator been built without, and why was it left out?

The calculator carries no field for which day's value applies, and the blank is a decision rather than an oversight. The conditions deciding which struck value attaches to an instruction, and what must reach the scheme before it does, are set by SEBI and are revised. A tool carrying one of them would not go out of date when they changed. The tool would go wrong, and keep producing confident outputs while wrong.

The same reasoning removes three more. Whether a smallest permitted sum exists, and what it is, are matters for SEBI at sebi.gov.in, so the tool carries no field for one. No permitted frequency, for the same reason. And no ceiling on the load slider past the 2.00 per cent picked as a top of scale, a number chosen only to make the plot readable. The box for a sum taken off before allotment starts at zero on the same principle.

A reader argues with a sentence and simply believes an output. A tool is the worst place to bury a condition that will change. A line of prose saying a condition applies invites a check. A field pre-filled with a figure does not; it looks as though the machine already knew. The instrument states its one assumption on its face at every setting, and the source holds the rest.

What has to be typed in, and where does each of those figures live?

Eight figures go into the tool and every one of them has its own home. Not one comes from this calculator.

One struck value belongs to one dealing day. Stripped of that day it can neither confirm nor contradict anything about an instruction priced on a particular one, so a figure that arrives without its day has not finished arriving. This is the commonest reason a reader's arithmetic fails to tie. Readers pull a value per unit from wherever it was easiest to find, usually the most recent, and run it against a transaction from weeks earlier. The arithmetic is perfect and the answer is meaningless.

The day is part of the number rather than a label beside it, in the way a train time means nothing without the day it belongs to. The tool cannot enforce that: a figure typed into a box carries no date, so the field note asks for the day and the arithmetic has no way of checking that one came with it.

Which is why the instrument takes both readings and shows what choosing the wrong one does. Leave the purchase attached to Rs 35.00, set the sending day box to Rs 34.50, and the last panel reports 2,898.551 units against the 2,857.143 actually allotted, a gap of 41.408 units. The sum handed over stays at Rs 1,00,000.00. Both misreadings have that shape, the money staying where it is while the unit count moves, and a reader checking only the rupees never sees either of them.

What has a matching answer actually established?

The arithmetic was done correctly, and that is worth more than it sounds. A match establishes that the division was right, the rounding convention was applied the way it was assumed, the load was struck on the base it was assumed to be struck on, and nothing unknown was added. Four possible faults eliminated in one step is a genuinely useful result.

Whether the instruction was priced against the day it should have been is untouched by any of that. Most reconciliation arguments end up there. The tool takes the value per unit as it is given and cannot know which day it belongs to, which day the instruction was considered against, or whether those are the same day. Given the wrong day's figure, it does perfect arithmetic on the wrong number.

So a match narrows rather than clears. Before it there were two kinds of query, an arithmetic one and an attachment one; after it there is one, and which one is known. The narrowing is smaller than most readers expect and far more useful than a vague sense that everything looks fine. A narrowed query goes to the registrar and transfer agent in one sentence instead of three.

Here is the whole default case in one place, every line computed from a value per unit of Rs 35.00. The Rs 35.00 is itself Rs 4,200 crore of net assets divided by 120.00 crore units.

Step nine is the line worth remembering. Two instructions that both revolve around Rs 35,000.00 and a thousand units end 10.101 units apart, and every rupee of that gap is the assumed load wearing a different unit of measurement. Steps ten and eleven are the two misreadings: each moves the unit count while the sum handed over stays exactly where it was.

Girnar Asset Management Limited, the Girnar Large Cap Equity Fund, the Girnar Broad Market Index Fund, Kalyani Bhagat and Sohail Merchant are invented.
Educational material. Not advice on any investment, tax, budget or market position.