Not All RRSP Contributions Are Equal

Ah, January, when thoughts turn to taxes.  I still do my own because my situation is pretty simple.  My yearly routine is to put on Ace Ventura Pet Detective and fill out forms for me and my wife.  Since switching away from paper forms a few years ago to the fabulous and free StudioTax I’ve been able to watch more of the movie.  StudioTax also has a special place in my heart because it’s written in .NET.  I’m guessing the name comes from the development tool .NET folks use, Visual Studio.

This post isn’t about StudioTax, though.  It’s about something I’m sure I’ve understood from newspapers and magazines turning out to be wrong: that your entire RRSP contribution results in a rebate equal to your highest tax rate.  This is the reason tax planners sometimes recommend not contributing to an RRSP until you are in a high tax bracket, like the last 2 federal ones.  You don’t want to waste getting about 40% back by contributing when you’ll only get about 32% back.  The advice is to set aside the money until you reach one of these brackets, just not in an RRSP.  These days that place would be a TFSA account.

It’s not so simple, though, as waiting until your total income moves you to a higher tax bracket and then plowing all of your savings into an RRSP account that year.

The Math

Disclaimer: I am not a tax planner, accountant or financial consultant. There are lots of other considerations than those below to make when deciding what’s right for your situation.  I’m just exploring something I came to realize recently, which applies to my situation.

The Canadian income tax system is what’s called progressive.  Not progressive in the “this is the better way” sense, but in the “progression from one level to another” sense.  Your entire income isn’t taxed at the same rate.  The first $x is taxed at a certain level, the next $y is taxed at a higher level, the next $z at an even higher level.  The feds have their own set of x, y, z values and rates, as does each province.  Except Alberta where there is no provincial income tax.

I’ll use small, hypothetical amounts for this discussion, and assume there are no automatic tax credits, as there are in the real tax system.

Let’s say the brackets and rates are:

Income	Rate
First $50	15%
Next $50	25%

You make $60 a year.  That means you owe:

Income	Tax Calculation	Amount
On the first $50	$50 x 0.15	$7.50
On the next $10	$10 x 0.25	$2.50
	Total	$10.00

Your employer would have taken this from your pay cheque, so you’ve already paid.  If you don’t do anything more to do with taxes you owe nothing and you’ll get nothing back.

Every dollar you contribute to an RRSP (or pension plan for that matter) lowers your taxable income by 1 dollar.  Let’s do the same calculation but with a contribution of $4.

Total Income	$60
RRSP Contribution	$4
Taxable income	$60 – $4 = $56

Plug $56 into the tax calculation table and you get:

Income	Tax Calculation	Amount
On the first $50	$50 x 0.15	$7.50
On the next $6	$6 x 0.25	$1.50
	Total	$9.00

You’ve paid $10 through your pay cheque, you owe $9, so you get a rebate of $1.  This is equal to your contribution times the higher rate, or $4 x 0.25 = $1.

However, if your contribution lowers your income into the next bracket down, the entire contribution is not worth 25%.  Only the portion that lowers your income to the edge of the higher bracket is worth the higher bracket’s rate.  The remaining portion’s rebate rate is the rate of the lower bracket.

To demonstrate, lets say you contribute $15 of your $60 income.

Total Income	$60
RRSP Contribution	$15
Taxable income	$60 – $15 = $45

Now you owe:

Income	Tax Calculation	Amount
On the first $45	$45 x 0.15	$6.75
	Total	$6.75

You’ve paid $10, you owe $6.75, so you’ll get a rebate of $3.25.  Note that this is not equal to your contribution of $15 times the higher rate, or $15 x 0.25 = $3.75.  This is because it’s a combination of the potion that brought your income down to $50 at the high rate, plus the remaining portion at the low rate.  That is:

Contribution	Rebate Calculation	Amount
Portion to get to $50	$10 x 0.25	$2.50
Remaining portion	$5 x 0.15	$0.75
	Total	$3.25

Conclusion

If you’ve been waiting to make contributions until you’re in a higher bracket, and you’ve finally reached that bracket, it’s not really worth contributing more than is enough to bring your income down into the next bracket.  In the example above, it’s not worth contributing more than $10 of the $15 to bring your income down to the lower rate.  Any more contributions will only earn a rebate of 15%.  You’re better to hold on to any other savings to use in future years in hopes that your income rises faster than inflation.

Web Client Software Factory vs. Code Metrics

 

I’ve been building a web application with the Microsoft Web Client Software Factory (WCSF), and it has an interesting default option.  The option is to put interface definitions in an assembly separate from the implementation when creating a new module.  This will generate 2 projects for each module, which means at least 2 namespaces, if you don’t change anything.  This post will investigate whether the code metrics generated by this approach, specifically abstractness and instability as defined by NDepend, are worth the increased maintenance compile time.

The option can be seen here when creating a foundational module in WCSF:

WCSF also presents this option when creating a business module, although it still places the interface for the module controller in the “concrete” project, not the interface project.

The effect is that you’ll end up with 2 new projects, as seen in the picture above; Blah, and Blah.Interface.  The thinking is that the projects that use the services of the module need reference only the interface project.  Dependency injection will take care of locating the actual implementations.  A rather high-minded architectural choice, especially considering that for foundational modules WCSF doesn’t even add a reference to the interface project to the web project.

Let’s say you follow the intention, though, and add some interfaces to Blah.Interface, some services that implement them to the Blah project, and some views in the web app that use the interfaces.  WCSF’s behaviour aside, what’s of real interest to me is how NDepend scores these 2 projects on the abstract/instability graph:

Blah is right near the WebClient5 assembly.  It’s perfectly instable, meaning no types depends on its types directly, and perfectly concrete, or non-abstract, because it has no abstract types.  It just implements abstract types.

Blah.Interface is perfectly abstract because it has only abstract types, and is very “stable” because while lots of types depend on its type, its types (interfaces) do not depend on anything else.  (NDepend claims Blah.Interface has 1 external type dependency, but I don’t know what.  If I eliminated this dependency then Blah.Interface would be perfectly stable.)

Now, compare the graph of the same project refactored to merge Blah and Blah.Interface:

Blah’s abstractness has increased and it’s “stability” has decreased.  These in themselves don’t mean much, but their relative values are still well within the area closest to the ideal dotted line. 

Given that NDepend suggests that this approach won’t result in pain or uselessness in this simple case, I conclude that the 2-project approach is not worth the extra maintenance.  This approach should be used only when it solves an actual problem, not by default for every module.