Can you please add a feature that would allow us to set up a recurring invoice? We would like to be able to have an invoice automatically post on the first of each month without setting up a plan for a determined amount of time.
Date
Votes
18 comments
-
Chad Egresi I agree, automatic invoicing for fees like registration, technology or continuous enrollment (in our case) would be very helpful. Setting something up that would allow us to charge all students, each term, who meet specific criteria, a specific fee would improve the efficiency of some of our processes that are currently manual.
Thank you
-
Jonathan White This would help us too for those who live on campus and get monthly fees.
-
Jonathan White Any update on this one Populi? It is one of the most basic financial functions that you are still missing... Every billing program in the world now has it and it is a big glaring hole here still.
-
Darbie Cook Is this a feature yet?
-
Jonathan White Nope, at least not that I know of
-
Kim Huizinga This feature would be SO helpful for us. We have continuous enrollment and have to bill students monthly. We have a tuition plan that works like a subscription and it would be so helpful to be able to set it up in one step rather than having to create the same invoice every month for our students. I tried billing for the whole year with a monthly payment plan but that messes up other statistics. PLEASE add this feature as soon as possible!!! Thank you!
-
Lorraine Ruiz Is this feature available yet?
-
Terry Van Gorkom Any update is this in the works? Seems like it would be a pretty standard option to make recurring invoices.
-
Adam Sentz You can already bulk invoice everyone with a few clicks on the Pending Charges report. We have some concerns about what sort of things might happen if many invoices are regularly generated without anyone reviewing the charges.
-
Jonathan White @Adam, we aren’t talking about invoices being posted. Posting pending invoices is relatively easy. We are talking about the generation of recurring regular monthly invoices. For example we have a list of numerous people who live in apartments on campus and they pay monthly. We have other monthly charges and Populi doesn’t have any option to create monthly invoices
without having a list outside of populi and manually creating the charges. I agree that recurring charges should come in pending just like other automatic semester charges. -
Jonathon Beeke Adding my voice to this. Can Populi confirm if subscription billing is on their radar??
Just to note, in addition to this request, there are a number of other requests for subscription billing:
https://support.populiweb.com/hc/en-us/community/posts/5823172214555-Fee-Rule
-
Jonathon Beeke Just one further comment: Populi charges on a subscription basis (https://populi.co/pricing/), so why not make this available as an option? ;)
-
VISIBLE Financial Office We really need this feature for monthly small amounts that are side agreements with students for certain services and spaces.
-
Jonathan White Once again, this seems like such an obvious need. One of the big ones that Populi finances still doesn't have. Any update on this? It seems like it shouldn't be that hard... every other financial system on the planet pretty much allows for recurring billing almost everything from cell phones, to internet, to rent, to Netflix and Spotify have monthly recurring charges/invoices. What are your concerns? If students are billed incorrectly that is on us and the students would be the first ones to complain. Not everything a student does with a school is on a semester basis.
-
James Hi Jonathan!
You're right that, from a technical perspective, this is a fairly easy problem to solve. What gives us pause is that for many parts of Populi (reporting, 1098Ts, term statements, financial aid, percentage-based awards, etc), to be fully accurate we really need charges pinned inside of academic terms. Sometimes we could deduce the correct term from a hypothetical recurring charge's invoice date, but it's very likely you would invoice a student for a dorm room before they arrive, or backbill them for an internet charge, etc, so that wouldn't always work cleanly.
What makes it really complicated is that, for a single monthly recurring invoice, some of the charges might logically be attached to one term and other charges attached to another, and then in the case of partial payments deciding how to affect term statements becomes a bit of a nightmare. And if we don't affect term statements at all with these new recurring invoices, would students find that odd to look at their term statement and NOT see several monthly "Dorm Room Rent" invoices that they know they paid during that term?
So we're hesitant to go down this road because it might tie folks' reporting up in knots, BUT we agree it would be a useful feature and would welcome your thoughts for how it would interact with reporting, 1098Ts, financial aid, etc?
All the best!
James
-
Jonathan White Hi James,
Thanks again for taking the time to lay this out — I do understand the concern, and I think you’re right that if recurring billing is implemented naively it could create real issues for term-based reporting, financial aid, and 1098-T accuracy.
That said, I think the root issue here may be that we’re trying to force all financial activity into a term-based structure, when in practice not all charges actually behave that way.
For example, things like tuition and aid are inherently term-based — but housing, internet, or other ongoing services are fundamentally date-based obligations that exist independently of the academic calendar. Most schools still need to manage both realities at the same time.
So instead of trying to make recurring charges fit cleanly into the term system, it might make more sense to let them exist alongside it, with clear rules for how (or whether) they interact with terms.
A model that might address your concerns while still solving the recurring billing need could look something like this:
- Recurring charges are defined by schedule (e.g., monthly), with a service date or period.
- At the time of generation, each charge can:
- Automatically map to a term based on its date (e.g., falls within Spring term dates), or
- Be assigned to a specific term explicitly, or
- Remain term-neutral (dashboard-only) for charges that don’t need to participate in term reporting or financial aid.
- Financial aid would continue to function exactly as it does now:
- Disbursed by term
- Applied only to aid-eligible charges tied to that term
- For visibility:
- Term-based charges would appear in By Term statements
- Term-neutral charges would still appear clearly on the overall financial dashboard, so students can see and pay them
This approach keeps the integrity of term-based reporting (since nothing is forced or guessed), while also allowing schools to handle real-world scenarios like monthly housing or service charges without manual workarounds.
In other words, the goal wouldn’t be to make recurring billing override the term system — but to let it respect the term system where appropriate, and stay outside of it where it doesn’t apply.
From a user perspective, I think most schools would be very comfortable with:
- clear defaults,
- the ability to override when needed,
- and the understanding that not all charges will appear on term statements if they aren’t meant to interact with aid or academic reporting.
Appreciate you engaging this — I think there’s a path here that preserves reporting integrity while still addressing a pretty significant operational gap.
Thanks,
Jonathan -
James Thanks for the feedback! We'll keep thinking about it, but unfortunately Title IV and some other regulations do require colleges to report charges in a way that is difficult (or impossible) to do accurately without shoehorning them into some sort of date-bucket structure like Terms/Cohorts/etc. Keep track of Financial Aid Food & Housing COA vs actual Food & Housing costs for a particular term is a good example. And if you chose to invoice tuition in a recurring invoice (which would be very convenient for several of our clients), then I don't see how you would answer the 1098T's Box 7 "Check if the amount in box 1 includes amounts for an academic period beginning... Jan 1 {next calendar year}" since there would be no way to tell if the invoice applied to a future term in the next calendar year? But we'll keep pondering it...
-
Jonathan White Hi James,
Thanks again for continuing to engage on this—I do understand the constraints you’re raising around Title IV and 1098-T reporting, and I agree those need to be handled carefully.
That said, I don’t think recurring charges themselves need to be restricted to being purely term-based. I think the key is when and how they are finalized into invoices.
What a lot of A/R systems do (and what has worked well in our experience) is this:
- You create recurring invoices and assign them to people
- But the system does not automatically post invoices indefinitely
- Instead, users run a manual “Generate Charges” process each month (or on a defined schedule)
That generation step is where control and compliance can be enforced.
At that point, you could:
- Generate charges for a group of people
- And require the user to decide how those charges should be handled:
- Assign them to a specific term, or
- Leave them on the dashboard (for non–Title IV / non-1098-T items)
If Populi wanted to enforce guardrails, it could simply require that any charge flagged as Title IV / 1098-T relevant must be assigned to a term at the time of generation
That way:
- You’re not relying on the system to guess term alignment
- You avoid the complexity of trying to auto-map based on dates (which can get messy with overlapping terms)
- And you still preserve full compliance, because nothing gets invoiced without a clear term decision
At the same time, this solves the very practical problem we’re facing. Today, in order to create monthly charges, we have to maintain external lists and manually go person-by-person to create the same charges every month.
With a recurring + generate model:
- The system handles the grouping and repetition
- The user retains control at the critical moment
- And we eliminate a lot of manual, error-prone work
So to me, this feels like a simple and elegant middle ground:
- Recurring charges exist at the user level
- Generation is still manual and controlled
- Term assignment is enforced only where necessary
Appreciate you continuing to think through this—it feels like there’s a path here that respects both compliance requirements and real-world operational needs.
Thanks,
Jonathan
Please sign in to leave a comment.