I have wrote an accounting system in Paradox 9. My problem is that I have many extra decimal places in the tables. The way the data is stored is giving me fits. I just want the tables to have 2 decimal places after the numbers but I am getting much more.

There tends to be a problem if you bill someone $10.12345. I have tried the Currency type field and Currency type variables, but no luck.

You can simply manage your data internally as longints (in code and tables), then show them scaled down by 100, so having two decimals.

I used a similar trick when i had to manage time durations that exceeded the 24h limit: i managed them internally as integer number of seconds, and showed them externally as a more readable format.

Paradox is like that. In fact most databases are like that. Numbers are stored as floating-point values, not as values with a fixed number of digits. This means that there will always be some imprecision. "Floating point number like pile of sand on ground: each time you pick one up and move it around, you lose a little sand and pick up a little dirt."
...
Some DBMSes provide a "currency" data-type that is specifically designed for this, and it is actually an integer, usually multiplied internally by 10,000 to give the effect of four fixed digits of precision to the right of the decimal. Other DBMSes use a format called "binary coded decimal" (BCD... ask your COBOL instructor...) which also provides this fixed precision.
...
You can even trick a desktop calculator to produce "off by one" artifacts, even when producing a paper-tape and with the machine set to X digits of precision. So the problem isn't peculiar to Paradox.
...
Also remember that "the sum of a list of rounded numbers" is not equal to "the rounded sum of a list of numbers." While the rounding algorithms used in Paradox ("banker's rounding") are designed to help the rounding-errors balance out instead of accumulating, totals can still wind up being off by, say, +/- 1 cent. (And you can make a calculator do the same error.)