Calculate invoice due dates in Make: 30 days vs one month

A 30-day invoice term can end on a different date from a one-month term. Make's date functions (opens in a new tab) let you calculate the date from the invoice's original issue date and check the result before using it.

This Make Free practice uses fictional dates and two built-in Tools modules. It produces due-date text, without creating an invoice, sending a reminder or connecting another app.

1. Choose the rule before the formula

Use this example when your agreed rule is a fixed number of calendar days after the issue date. Confirm the number, the starting date and any weekend or holiday adjustment in your actual payment terms. The formula cannot decide those rules for you.

If your invoicing app already calculates the correct due date, keep that setting. For a few invoices, a manual calendar or spreadsheet may be enough. Make is useful when an existing workflow needs to calculate the same date for each incoming record.

2. Create a fixed invoice-date input

1. Open Scenarios, click Create scenario and name it Invoice due date practice.
2. Choose Tools > Set variable.
3. Set Variable name to invoice_date and Variable value to 2027-01-31. Click the module's Save button.

This means 31 January 2027. Use a valid date written as YYYY-MM-DD, with no time or time-zone offset. Keep the original issue date for every rerun. Using today's date would move an old invoice's calculated deadline each time you processed it.

Enlarge image

Make Tools input named invoice_date with the fictional value 2027-01-31.

×

Open full-size image

3. Calculate 30 days after that date

1. Click the plus on the right of the first module and choose Tools > Set variables.
2. For Variable 1, set Variable name to due_date. Paste this expression into Variable value.

3. Check that 1. invoice_date is a coloured mapping token. If your source module has another number, replace that reference using the mapping panel.
4. Click the module's Save, then Save on the bottom scenario toolbar.

parseDate reads the text as a date. addDays adds 30 days, and formatDate returns the result as YYYY-MM-DD text. Uppercase MM means month. See Make's parsing-token reference (opens in a new tab) for other input formats.

UTC is explicit here to keep a date-only calculation in one consistent zone. This is not a conversion of an actual local timestamp. If your source includes a time or offset, preserve its meaning and use a matching parse format. The UTC-to-local-time guide covers a separate conversion task.

Enlarge image

Make Set variables formula parses invoice_date in UTC, adds 30 days and formats a date.

×

Open full-size image

4. Check days against months and weekends

1. Reopen the second module and click Add variable.
2. Name it one_month_later and paste the comparison below into its Variable value. Save the module and scenario.

3. Click Run once. Open the result bubble above the second Tools module.
4. Under Output, check due_date: 2027-03-02 and one_month_later: 2027-02-28.

Enlarge image

Make output shows 2027-03-02 after 30 days and 2027-02-28 after one month.

×

From 31 January 2027, adding 30 days gives 2 March; adding one month gives 28 February.

Open full-size image

Adding one month is not a substitute for adding 30 days. In this example the two results differ by two days. Change the first module's input to 2028-01-31, save it and run again. The leap-year results are 2028-03-01 for 30 days and 2028-02-29 for one month.

Enlarge image

Make leap-year output shows 2028-03-01 after 30 days and 2028-02-29 after one month.

×

In the leap-year example, 30 days gives 1 March and one month gives 29 February.

Open full-size image

For a weekend check, change the input to 2026-10-09 and change 30 to 2 in the due_date expression. Save both changes and run again. Friday plus two days produces 2026-10-11, a Sunday. The separate one_month_later comparison still adds one month. A rule that requires business days or holiday adjustments needs additional calendar logic.

Enlarge image

Make output shows Sunday 2026-10-11 after adding two days to Friday 2026-10-09.

×

The due_date formula adds two calendar days here and returns Sunday.

Open full-size image

5. Check a rerun and a failed input

1. Restore invoice_date to 2027-01-31 and the due_date expression to 30 days. Save both modules and the scenario.
2. Run it twice. Each run should produce 2027-03-02. The fixed input keeps this calculation stable.
3. For a failure check in this practice scenario, replace the input with not-a-date, save and run. Open the error bubble above the second module.

The observed result is DataError, with a message that the value is not a valid date or does not match the format. That operation produces no output bundle.

Enlarge image

Make DataError says not-a-date is invalid or does not match the date format.

×

Open full-size image

Restore the valid input, save and run again before leaving the scenario. Keep it Inactive. Repeating this calculation does not prevent duplicate invoices or reminders in a larger workflow. Those actions need separate checks to prevent duplicates.

If the due date is wrong

Check the original issue date, agreed day count and input format first. For an ambiguous value such as 04/05/2027, confirm whether it means 4 May or 5 April, then use the matching input format. A blank, invalid or unexpected input needs review before it reaches a billing action; the not-a-date failure above is one specific check, not proof that every malformed date is rejected.

Keep the output zone consistent with this date-only example. Displaying the parsed value in another zone can change its calendar date. Use Make's formatting-token reference (opens in a new tab) if you need another display format. A destination that expects a date value rather than text needs its own field-type check.

Before connecting this to real billing, compare several known invoices against your existing system, including month-end and any weekend or holiday rule. Check the destination's input type and duplicate behavior with a harmless record. Only then map the verified date into the relevant field. This practice does not schedule a payment or guarantee when a customer will pay.

To check the fictional invoice dates before connecting a billing app, start with Make Free (opens in a new tab) and run the practice manually. Keep the scenario inactive and verify your real billing rules separately.

Sources: Make date and time functions, date parsing and formatting token references, and the plan limits linked above. The fictional example's outputs and failure were checked in a native Make Free scenario.