The top mistakes

Below are some of the most common alimony and child support calculation mistakes we see when people use DocketMath for Rhode Island (US-RI) workflows. These issues usually come from incomplete data, using the wrong default timeline assumption, or misunderstanding what your inputs do to the calculator outputs.

1) Using the wrong “default” timeline for general filings

Rhode Island has a general SOL (statute of limitations) period of 1 year under General Laws § 12-12-17. A common error is treating that 1-year period like it’s claim-type-specific—even though the rule being cited here is a general/default period.

• What goes wrong: people apply the same limitation period to a specific support dispute without confirming whether a claim-type-specific statute applies.
• What to do instead: use the general 1-year default only when you’re working from that broad rule and you don’t have a claim-type-specific statute identified.

Source for the general/default period: General Laws § 12-12-17 (Rhode Island’s general SOL period is 1 year).
Link: https://codes.findlaw.com/ri/title-12-criminal-procedure/ri-gen-laws-sect-12-12-17/

Clear takeaway: In this article, the 1-year SOL is presented as the general/default rule—no claim-type-specific sub-rule was identified for a more specific category in the available rule summary.

2) Entering income that’s too high (or too low) due to inconsistent definitions

DocketMath outputs depend heavily on the income numbers you feed in. The most frequent data error is mixing sources that don’t line up, such as:

• annual vs. monthly numbers
• gross vs. net pay
• base salary vs. bonuses/commissions
• regular overtime vs. one-time overtime

Typical symptom: your child support or alimony estimate looks “off” because the calculator is doing exactly what you asked—using inconsistent income definitions.

3) Omitting dependents or mis-typing time-sharing inputs

For child support estimates, small input changes can shift results. Common mistakes include:

• leaving the number of children blank or entering the wrong number
• entering parenting-time in the wrong format (or omitting it)
• using an “average time” concept when the tool expects a different time breakdown

Practical example: if you update the number of children but forget to adjust related parenting-time assumptions, the output can swing in a way that looks like an error—but it’s really an input mismatch.

4) Treating “support” categories as interchangeable (alimony vs. child support)

Alimony and child support are not the same category in purpose or typical modeling logic. A frequent workflow error is entering combined totals or trying to back into one category using a number that already includes the other.

• What goes wrong: double-counting (or cancelling) amounts because you treat them as the same bucket
• Result: your estimate may not match the court order you’re trying to model because your inputs don’t reflect the calculator’s separation logic

5) Editing one input without checking related fields

Even if you change only one value—like income—other fields can become inconsistent with your update. Examples:

• updating income but leaving frequency/unit conversions unchanged
• changing filing or effective-date assumptions in your notes while leaving the calculator inputs untouched
• entering numbers inconsistently (for example, treating “$60,000” as both 60,000 and “60000/12” in different places)

Result: the estimate updates, but not in the direction you expect.

6) Relying on output without tracking what it is and isn’t

DocketMath is meant for estimates and scenario modeling. A common error is treating an estimate like a court-determined obligation.

• Use the output to understand “what changes when X changes.”
• Keep a separate record of the assumptions used (income frequency, categories included/excluded, children count, time-sharing inputs).

This makes it easier to revise inputs accurately and compare versions.

How to avoid them

A strong process beats a “perfect entry.” Use this practical checklist before and after you run DocketMath.

Start with a single source of truth for each input

Create one mini-workpaper (even a note on your phone) listing:

• your income figures (with frequency: weekly/biweekly/monthly/annual)
• any additional regular income sources you plan to include
• the number of children
• the parenting-time structure you intend to model

Then apply the same definitions consistently across every related input.

Use the DocketMath flow and rerun after every meaningful change

If you’re using DocketMath, open it from the intended path so you’re working in the correct workflow:

• Primary CTA: alimony-child-support

When you update inputs:

1. rerun the calculator
2. compare the new output to the previous output
3. record what changed (e.g., “output increased after switching income frequency”)

Verify timeline assumptions using Rhode Island’s general SOL rule (1 year)

If the question involves a general timeline (rather than a claim-type-specific limitation), anchor your planning to Rhode Island’s general/default SOL:

• Default: 1-year general SOL period
• Caution: This is the general/default rule, not claim-type-specific (no claim-type-specific sub-rule was identified in the available rule summary).

Statute reference: General Laws § 12-12-17
Link: https://codes.findlaw.com/ri/title-12-criminal-procedure/ri-gen-laws-sect-12-12-17/

Keep category separation clear (don’t blend alimony and child support)

If you’re modeling a scenario, keep totals separated:

• Child support inputs → child-support portion of the estimate
• Alimony inputs → alimony portion of the estimate

If you’re working from an existing order amount, avoid re-entering combined totals into fields the tool expects to estimate separately.

Use a quick “input consistency” table before you hit calculate

Do a fast consistency check like this:

Watch for unit-conversion errors (the most common “silent” error)

Before rerunning, confirm:

• annual income is entered as annual (not monthly)
• monthly income is entered as monthly (not annual ÷ 12 “somewhere”)
• time units and percentages match what the tool expects

Example: if you switch from biweekly to monthly but keep the same numeric value without converting frequency, the estimate can become dramatically inaccurate while still appearing “internally consistent.”

Practical caution: Even when everything looks tidy, wrong unit conversions often produce results that are confidently—but incorrectly—presented.

Related reading

• Browse the blog

The top mistakes

• missing a required input
• using a stale rate or rule
• ignoring calendar or holiday adjustments
• skipping documentation of assumptions

When rules change, rerun the calculation with updated inputs and store the revision in the matter record.

If an assumption is uncertain, document it alongside the calculation so the result can be re-run later.

How to avoid them

Use a written checklist for inputs, document each source, and run a quick sensitivity check before finalizing the result. When two runs differ, compare inputs line by line and re-run with one variable changed at a time.

When rules change, rerun the calculation with updated inputs and store the revision in the matter record.

Related reading

• Alimony & Child Support Estimator Guide for Alabama
• Alimony & Child Support Estimator Guide for Arizona
• Alimony & Child Support Estimator Guide for Colorado