StewaraGuidesWorship
Your set list is not evidence.
It is what you meant to do. Then the sermon ran long and the closer got cut, somebody called an old chorus from the floor, and the second service went differently from the first. Six months later a volunteer will report the set list anyway, because it is the only thing written down.
Somebody wrote that song, and this is how they get paid
Start with the part that usually gets skipped, because everything else follows from it.
Song usage reporting is not a compliance chore invented to annoy churches. It is the mechanism by which the money reaches the person who wrote the song. A licensing body collects from churches across the country and distributes to writers and publishers, and the only thing telling it who to pay is what churches report singing.
That reframes what a sloppy report actually is. If your church reports the four songs everyone remembers and forgets the one you did once in the spring, the writer of that one does not get a slightly smaller share of something abstract. They get nothing from your church, and they will never know, and neither will you.
Most of the people writing the songs your church sings are not wealthy. A good number of them are worship leaders at churches roughly the size of yours.
None of which makes the reporting less tedious. But it does change what you are doing when you sit down to it, and it is the reason the rest of this article treats accuracy as a moral question rather than an administrative one.
The plan is not evidence
This is the gap that nearly every reporting system, and nearly every church, quietly ignores.
A set list is a plan. It is written on Tuesday and describes what you intend to do on Sunday. Reporting asks a different question: what did you actually do?
Those two things come apart every week, and every worship leader reading this already knows how. The sermon ran long and you dropped the last song. A guest speaker went twenty minutes over and you dropped two. Somebody in the room started an old chorus in the gap and the band followed. The nine o'clock did the full set and the eleven o'clock did not. You added a hymn at the last minute because of who was in the hospital.
None of that is disorganization. It is what it looks like when a service is a living thing rather than a script, and most weeks the changes are the best part.
But it means that a report generated from your plan is a report of your intentions, and if you never write down what actually happened, the plan is the only record that exists, so the plan is what gets reported. Forever.
Reconstruction is not reporting
So the deadline arrives, and here is how it actually goes in most churches.
Somebody blocks out an afternoon. They open the planning software, scroll back through months of Sundays, and copy song titles into a form. Where the record is thin they ask the worship leader, who is doing this from memory across a period long enough that Easter and a funeral and two guest speakers have blurred together.
Then there are the songs with no number. Somebody starts searching titles, finds three arrangements of the same hymn with different numbers, picks one, and moves on, because it is late and this has already taken two hours.
What comes out the other end is a document that looks exactly like a report. It has song titles in it. It was filed on time. Nobody could tell by looking at it that a third of it is a reasonable guess.
And the honest problem is not that these people are careless. It is that they were handed an archaeology project and asked to produce evidence. The information they needed stopped being available within about a week of each service, and no amount of diligence in the sixth month recovers it.
What a record you could defend actually looks like
Suppose somebody asked your church to show its working. Not an accusation, just a question: how do you know you sang that song, on that date, that many times?
Four properties separate a record that answers that from a document that merely asserts it.
It was written down close to the event, by somebody who was there. A record made on Sunday by the person who led is a different class of thing from a reconstruction made in a hurry by somebody who was not.
It cannot be silently rewritten by an unrelated edit. This one is subtle and it is where most systems fail. If your record of what you sang in one week is generated from a plan that anybody can still edit, then somebody tidying up an old service next year quietly changes your reporting history, and nothing anywhere records that it changed.
It shows its gaps rather than hiding them. A report that cannot tell the difference between a service you confirmed and a service nobody has looked at is a report that will pass off silence as a zero.
And it keeps its own history. Who confirmed this, when, and what did they say before they changed their mind. Not because anyone expects to be audited, but because a record you cannot trace is a record you are asking somebody to take on faith.
Before you let software report for you
Automatic reporting is real, it is offered by more than one planning product, and on balance it is a good development. A church that reports automatically is a church whose writers get paid, and any church currently reporting nothing should take the automatic option and be glad of it.
Understand what it is doing, though, because the mechanism matters.
Most automatic reporting sends your service plans. Which means everything in the second section of this article now happens at scale and without anybody watching: the cut songs are reported as sung, the one somebody called from the floor is not reported at all, and the difference between the nine and the eleven never existed as far as the record is concerned.
That is still better than nothing, and considerably better than an afternoon of archaeology. It is just not the same as reporting what you used, and the marketing rarely draws the distinction.
So the useful question to ask is not whether a product reports automatically. It is what it reports automatically. If the answer is your plan, then somebody at your church still needs a habit of noting the weeks that went differently, or your reporting will be confidently, permanently, invisibly wrong in whichever direction your Sundays happen to drift.
How we do it
How Stewara does it
Stewara treats the plan and the record as two different things, on purpose, because they are. The schema says so where it is hardest to argue with: “A plan is intent, not evidence that a song was actually used.”
So after a service you confirm what actually happened, and that confirmation is a snapshot rather than a pointer. It stores the date, the service, the song title, the author and the number as they stood at that moment. A later edit to the plan, a renamed song, even a deleted item from the set cannot reach back and change what your church reported.
Confirming is the part that has to happen on Sunday, so it is on the phone. A worship leader with a guitar case in one hand opens “Confirm Sunday's songs”, sees the set from the service that just happened, and taps each song “Sang it” or “Skipped”. Two switches cover the ordinary case, “Words were on a screen” and “Service was streamed”, and the screen says where the rest lives rather than cramming it in: “Counts, printed copies, and anything unusual can be added on the web CCLI page. Nothing is sent to CCLI — this records your church's own answer.”
Everything else stays on a desk, deliberately. The exception queue, the date ranges, the worksheet, the checksum and the batch history are a sitting-down job, and the phone screen does the one part that stops being possible once you leave the building.
The web page is called “CCLI reporting”, and its three steps are labeled “1. Planned”, “2. Actual use confirmed” and “3. Recorded in CCLI”. What you confirm is not one number: each song carries digital, print, recording, translation, streaming and rehearsal occasions separately, because those are separate permissions and separate questions.
Anything unresolved sits in an exception queue rather than being quietly averaged away, in four plain states: “Needs confirmation”, “Plan changed”, “Missing CCLI number” and “Saved snapshot”. If a plan was edited after you confirmed it, that is its own state, and you get told rather than overwritten.
A hymn is the interesting case, because it will never have a number and used to sit in that queue forever. A song can now be marked “This song doesn't need a CCLI number”, which stops the queue asking and still counts the song every time you sing it. The wording is careful about whose decision that is: “Stewara can't know that for you, and a newer arrangement of an old hymn can still be under copyright.” Nothing is inferred from a title, an author or a date. It is a church saying so.
Marking a song is itself a change to the facts a confirmation answered, so an earlier confirmation of that song resurfaces as “Plan changed” and somebody re-confirms it. That is the same discipline as everything else here: the marker gets snapshotted into the record rather than quietly applied backwards to reports you already filed.
Your church's own license number lives in Church profile under “Song licensing (CCLI)” and prints on the worksheet and in the CSV, so whoever is holding the printout knows which license it belongs to. It is copied from your CCLI account and never checked against it, and the screen says so.
And the export is locked until the range is provably complete. Not a warning you can dismiss: if anything in that period is unconfirmed, or the range is too wide to load in full, both Print and CSV are switched off. A worksheet that quietly omitted three Sundays is worse than no worksheet, because it looks finished.
Every export writes an audit row before the file reaches your computer, with a checksum, the range, the row count and who generated it. Every confirmation keeps its own revision history: who said what, and when they changed it.
Now the honest part, and it is on the page itself rather than buried in a support article. “Honest status: Stewara does not send data to CCLI yet. An export here is a worksheet for CCLI's reporting site; 'recorded' is a staff attestation after that manual step.” Automatic submission needs a partner arrangement we do not have, and products that have one hold a real advantage there. Marking a batch “Recorded in CCLI” is somebody on your staff saying they entered it, and the confirmation dialog says so plainly rather than stamping it because a file downloaded.
Two limits worth knowing. A song carries one author field and no publisher, so if your license needs a publisher named you are keeping that somewhere else. And reporting needs the Worship module, which is on the Growth and Complete plans rather than Basic.
The short version
The reason reporting goes wrong is almost never dishonesty. It is that the evidence stopped existing before anybody wrote it down.
- Reporting is how the writer gets paid. Under-reporting is not a filing error with no victim.
- Your set list is a plan. What you actually sang is a different fact, and only one of them is evidence.
- Ninety seconds on Sunday beats an afternoon in the sixth month, and produces a better answer.
- Ask whether editing an old plan changes what the system says you reported. If it does, that is a view of your plans rather than a record.
- Automatic reporting is worth having. Ask what it reports automatically, because most of them report the plan.