From a FreeAgent user’s perspective (ie. when a human uses the web based UI, rather than the API), when setting up an invoice, or recurring invoice for a subscription based service, it would be more convenient to complete a due_on field, than to calculate the payment_terms_in_days. In the UI’s current state, the due_on field isn’t exposed. Of course, if calling the API directly, one could automate the calculation (on the API client-side) beforehand.
Example monthly subscription:
Invoices are sent every month, on the 21st day
The due date is the 1st day of the next month
Example annual subscription:
Invoices are sent a calendar month in advance of renewal (1st of the month)
The due date is the 1st day of the next month
I would imagine that the following would be the simplest approach to improving this UX issue:
Use a radio selection on the UI, to specify either option. In the background, if due_on is selected, the UI calculates the mandatory payment_terms_in_days field and inserts it.
I’d like to bump this post for consideration again.
When setting up recurring invoices via the UI, it would be really helpful to have more control over invoice due dates, since months differ in their number of total days. So, the limitation of only being able to specify payment terms in days from the invoice date ends up generating inconsistent payment dates with respect to the next month. For example, invoices sent on the 25th with payment terms of 5 days would yield a due payment of 3 March for Feb invoices, 30 Oct for October invoices, etc.
I’ll try to rephrase the feature suggestion for my original post with a UI mock-up suggestion:
For monthly recurring invoices:
Due day: [day/days_before_last_day/last_day] { n }
Due month: [next_month/this_month]
For annual recurring invoices:
Due day: [day/days_before_last_day/last_day] { n }
Due month: [month]
Where:
[day/days_before_last_day/last_day] = drop-down selector
{n} = text box greyed out if 'last_day' selected
Since the API’s field is a date field, this wouldn’t involve changes to the API; only the interface.
Hi @zoot, thanks for getting in touch to share your suggestion, we’re always really eager to hear ways to improve FreeAgent for our users!
I’m a member of the engineering team that looks after recurring invoices, and I’ll make sure to flag this up with the product team for you. If we have anything more concrete around what we’re planning for recurring invoice improvements, I’ll be sure to let you know.
I recently spoke with Lesley of your support team and would like to share what I suggested to her, which would ultimately trickle down to the engineering team:
Ideally, the following would give the required flexibility.
For monthly:
day [x] of [current/next] month
For yearly:
day [x] of month [y]
How day [x] might work:
where forward counting days are positive integers and backward counting ones negative integers:
x = 1 for 1st day
x = 2 for 2nd day
…
x = -1 for last day
x = -2 for 2nd last day
It’s how one can reference arrays from the front or back in some programming languages.
On the other hand, it may be a more consistent user experience if the due date field supported the already existing invoice variables? That would however preclude the ability to set last, 2nd last, 3rd last day etc.