Verra VCS Version 5 and CCB: what the new templates ask of field data
Updated: 13 hours ago
On 27 October 2026 Verra published eight combined templates that pair Verra VCS Version 5 with the Climate, Community & Biodiversity (CCB) Standards, so a project reporting both carbon and co-benefits can file one project description and one monitoring report, with matching validation and verification reports. Projects that start before 1 July 2027 use the v5.0A set; projects that start on or after that date use v5.0B. For CCB projects the real work sits behind the forms: community and biodiversity monitoring evidence that a verifier can trace.
We've read Verra's announcement, its notice on the new effective date and the CCB Standards text. Below we cover what changed and which template applies, then what to keep ready in the field. If you want the wider picture of how community surveys relate to Verra methodologies, our Verra methodology alignment page covers it.
What Verra released on 27 October 2026
Version 5 itself isn't new. Verra launched Version 5 of the VCS Program on 16 December 2025, with stronger consultation and free, prior and informed consent requirements for Indigenous Peoples and customary rights holders. It also moved projects to shorter crediting periods with more frequent baseline reassessments, and it opened a pilot for new ways to manage non-permanence risk. What arrived in October is the paperwork for projects that report under both VCS and CCB.
The announcement on verra.org lists templates for projects registered, or seeking registration, under both programmes. There are four document types:
Project Description Template
Monitoring Report Template
Validation Report Template
Verification Report Template
Each one comes in two versions, "VCS v5.0A + CCBS v3.0" and "VCS v5.0B + CCBS v3.0". That makes eight documents in all.
Verra says the templates carry Version 5's new and revised reporting requirements, among them safeguards and stakeholder engagement. Its Version 5 resources page puts the people side plainly: "Stronger protections for Indigenous Peoples and local communities are embedded directly into project design".
CarbonCredits.com covered the release on 30 October and reads it the same way. Developers have to check start dates and submission timing to choose the right version, and auditors now review both programmes against one set of forms.
Which Verra VCS Version 5 template applies to your project
The project start date decides it. Verra's rules, as published on 27 October:
Start date before 1 July 2027: use the VCS v5.0A + CCBS v3.0 templates.
Start date on or after 1 July 2027: use the VCS v5.0B + CCBS v3.0 templates.
Earlier projects may move to v5.0B early. They must switch at their next crediting period renewal, or at their next baseline reassessment request submitted after 1 January 2030.
From 1 July 2027, every project review request under the VCS Program has to use the applicable Version 5 template, and that includes joint VCS and CCB requests for registration or verification approval.
There's a digital track too. Verra's notice on the new effective date says "The digital versions of VCS Version 5 templates are on track to be available January 1, 2027", so that projects using digitalised methodologies can submit through the Verra Project Hub.
One small warning if you're checking dates yourself. One FAQ answer on Verra's resources page still says that most Version 5 requirements become effective from 1 January 2027. Further down, the same answer records that in October 2026 Verra moved most of them to 1 July 2027. Go by the later date, which matches the 27 October notice.
Why the date moved, and what the extra months are for
Verra moved the effective date from 1 January 2027 to 1 July 2027 after feedback from projects finishing audits under Version 4. The notice is candid about the bottleneck: "The volume of projects seeking to meet the original deadline has also placed significant pressure on VVB capacity."
Projects that haven't yet started an audit or public comment period are "strongly encouraged" to prepare their documents under Version 5 as early as possible. That way they avoid rewriting documents and repeating audits if their timeline slips past July.
Verra presents the release as bringing the joint templates into line with Version 5. It doesn't announce changes to the CCB Standards themselves, so the monitoring requirements a CCB project already answers to still apply. What changes is the paperwork that carries them. For most CCB teams the useful thing to do with the extra six months is to check that the monitoring evidence behind the new forms is complete.
What CCB monitoring asks of field data
The CCB Standards text that Verra links is the Third Edition, Version 3.1, dated 21 June 2017. (The template names refer to CCBS v3.0; the requirement codes below come from the v3.1 text.) Four requirements decide most of what a field team records.
CM4, community impact monitoring. The plan has to name the community variables and the groups to be monitored. It also sets out the measurement types and sampling methods, plus how often monitoring happens. Variables must link to the project's causal model. Monitoring has to assess impacts for each community group separately, and it must include an evaluation by the affected groups themselves. The standard's examples start with income and employment and go on to health and food security. That evaluation can happen through participatory rural appraisal, community meetings or another documented process.
B4, biodiversity impact monitoring. Same shape. The plan names the biodiversity variables and the areas to monitor. It also sets the sampling methods and how often monitoring and reporting happen. The variables themselves must link directly to the project's biodiversity objectives and to its causal model. Suggested variables include species abundance and population trends. Habitat area and quality count too, as do landscape connectivity and forest fragmentation. A second plan checks whether the measures protecting the project zone's high conservation values are working.
Publishing results. Both CM4 and B4 require the monitoring plan and its results to be publicly available online, with summaries communicated to communities "through appropriate means".
G3, stakeholder engagement. G3.6 asks how communities take part in monitoring and evaluation, in a culturally appropriate and gender-sensitive way. G3.8 asks for a formal grievance procedure with three stages: an amicable attempt with a written response, then mediation by a neutral third party, then arbitration or the courts. Grievances and the project's responses must be documented and made public.
Here's how that turns into a VVB's questions:
CCB requirement | What a VVB will look for | Field evidence worth keeping |
|---|---|---|
CM4.1 community impact monitoring | Variables linked to the causal model, results for each community group, the communities' own evaluation | Dated survey records split by community group, and notes from evaluation sessions |
B4.1 biodiversity impact monitoring | Sampling that matches what the plan promised | Timestamped observation records with a location and a photo or recording, plus the method used |
CM4.3 and B4.3 dissemination | Plan and results online, summaries back in the communities | Copies of the summaries, with the language and channel used |
G3.6 participation | Who monitored, and how women and vulnerable or marginalised people took part | Participant lists by role and training records |
G3.8 grievance redress | A working three-stage process that is documented and public | Each grievance with its status history and the project's response |
Where community-led dMRV fits
CCB's monitoring requirements assume that communities take part in collecting and judging the evidence. That's the work community-based monitoring is built around, and it's where a phone-based tool can keep the trail tidy. Here is what the CitizenClimate app does today, as the App Guide and the Data Integrity & Methodology Protocol describe it.
Records survive bad signal. Surveys work offline and submissions queue on the phone. When it syncs, the original field timestamp is kept and the sync date is recorded separately, so a verifier can see when an observation was made.
Nothing is quietly removed. Submissions can never be deleted. A faulty record is archived with a reason from a fixed list, and VVBs can still see it. Editing a survey never changes answers already collected.
Results by community. The Protocol says community-level averages are calculated separately, so a VVB can see SDG scores broken down by community within a project. Where a project sets up its communities to match the groups in its plan, that helps with CM4's request to look at each group separately.
Biodiversity records with context. A survey question can ask for a photo or an audio recording, a GPS point or a species identification. For each identification the AI returns scientific and common names with a confidence score, plus the species' IUCN Red List status. A photo taken offline is identified once the phone reconnects. The biodiversity monitoring dashboard reports diversity indices such as Shannon-Wiener and Simpson's, and the records export as CSV or JSON.
Grievances on the record. Members file a grievance that moves from Pending to Under Review to Resolved, and the project developer can reply with a resolution note. Grievances can't be deleted, and the member's name isn't shown to the developer or other members. VVBs can read every grievance with its full status history.
Direct access for auditors. The VVB role is read-only, with direct access to project data rather than to reports the developer has prepared.
Eleven languages. The app runs in 11 languages, which helps when information has to reach people "in a language and manner understood" by them, as G3 puts it.
The limits matter just as much. The app doesn't fill in Verra's templates, and it doesn't submit anything to Verra. Its exports are raw CSV and JSON records that the project team and the VVB work from. The grievance channel records and tracks concerns, but G3.8's mediation and arbitration stages happen outside the app, and the project decides what it publishes. The platform also doesn't set what a monitoring plan should measure. That's the project's design decision, checked by its VVB.
CitizenClimate's data is structured to align with the monitoring requirements of Verra VCS, Gold Standard, Plan Vivo, Puro.earth and Carbon Standards International. CitizenClimate is not certified, accredited or endorsed by any standard body, and it does not issue credits. We aren't affiliated with Verra. For why traceable field data matters to credit buyers, see why dMRV is the missing link in carbon credit quality.
What to do before 1 July 2027
Check your project start date and note which set you'll use, v5.0A or v5.0B.
If you haven't started an audit or public comment period, think about preparing under Version 5 now, as Verra recommends.
Map each CM4 and B4 variable to a survey question, then write down how often it's sampled and by what method.
Record the communities' own evaluation of impacts, not only the indicator values.
Test the grievance procedure end to end, including who the neutral mediator would be.
Decide where the monitoring plan and results will be published, and in which languages the summaries go back to communities.
Ask your VVB early which raw records they'll want to read, and in what format.
Frequently asked questions
What is Verra VCS Version 5?
It is the current version of Verra's Verified Carbon Standard Program, launched on 16 December 2025. It sets a higher bar for safeguards and stakeholder engagement, with stronger consent requirements for Indigenous Peoples and customary rights holders. Crediting periods are shorter and baselines are reassessed more often, and there is a pilot for managing non-permanence risk. Most of its requirements now take effect on 1 July 2027.
When does Verra VCS Version 5 take effect?
Verra moved the effective date for most Version 5 requirements from 1 January 2027 to 1 July 2027, in a notice dated 27 October 2026. From 1 July 2027, project review requests have to use the applicable Version 5 template, including joint VCS and CCB requests. Projects can use Version 5 templates before then.
What is the difference between the v5.0A and v5.0B templates?
The start date decides. Projects starting before 1 July 2027 use v5.0A, and projects starting on or after that date use v5.0B. Earlier projects may adopt v5.0B voluntarily, and must switch at their next crediting period renewal or their next baseline reassessment request submitted after 1 January 2030.
Do the combined templates change the CCB Standards?
Verra's announcement doesn't say so. The templates pair VCS Version 5 with CCBS v3.0 so both programmes report through one set of documents. The CCB requirements on community impact monitoring (CM4), biodiversity impact monitoring (B4) and grievance redress (G3.8) still apply. What changes is the document format and the Version 5 reporting on safeguards and stakeholder engagement.
Can a grievance app meet the CCB grievance requirement on its own?
No. CCB G3.8 asks for a three-stage procedure: amicable resolution with a written response, mediation by a neutral third party, then arbitration or the courts. An app can record and track grievances and keep them from being deleted. The project still has to organise mediation and arbitration, and publish the grievances and its responses.
Getting your monitoring ready
The template change is mostly a paperwork exercise. The evidence behind it isn't, and six extra months is a reasonable window to get community and biodiversity records into shape before a VVB asks for them. Download the free app to try the survey builder and the grievance screen with your team.
Comments