Introduction

The Property Tax System(PT) provides a digital interface to make property assessments, pay property tax, generate payment receipts and monitor tax collection. It can be used by the citizens, Urban Local Body (ULB) counter and field employees and ULB Administrators to accomplish their specific tasks. It is available as a mobile and web-based application.

Functional Scope

The PT product features can be broadly classified as the following modules:

1. Registration, Login and Creation of User Profile

2. Filling an Assessment for a Property

3. Searching for a Property

4. Modifications to a Property

5. Generate Demand Notice

6. Payments collection and Receipts

7. Dashboards and Reports

8. General Features

Registration, Login and Creation of User Profile

Filing For Property Assessment

With this feature, a citizen and employee can perform a self-assessment of a new property for a financial year. This feature helps in registering the property in the system. The details of the property can be entered online and can be assessed for the calculation of the taxes.

The PT Product is designed in a user friendly manner and reduces chances of error. System calculates the tax automatically and creates the demand. If a user wants to reassess his property due to any reason (for eg, incorrect data, change in property etc), it can be done by editing details of the last assessment.

An employee can edit the details of the last assessment, on behalf of the citizen-based on the owner’s input. Citizen can track down the status of his incomplete assessment. Any incomplete assessment can be searched and completed.

Searching for a Property

Citizen or Employee can track down the status of his incomplete assessment. Any incomplete assessment can be searched and completed.

Modifications to a Property

The PT system provides the ability to capture mutation and transfer of ownership. It reduces interfaces between the user and the State and thus promote greater transparency. It also helps in reducing the time taken for mutation after registration. The system provides the ability for alteration of assessment after verification and inspection. Any structural changes like addition/extension/reduction of existing built up area or construction type OR utility changes like usage or occupancy have an impact on the increase/decrease in property tax demand. These changes can be handled by the ‘Additional/Alteration of Assessment’ feature.

The System provides the ability for bifurcation/ amalgamation of property. The property bifurcation/ amalgamation undergoes an approval process. The parent property needs to be modified accordingly, which can be done in the system.

Generate Demand Notice

System has the capability to automatically generate demand notice for a financial year based on set triggers like time-based roll over on completion of a financial year. The system notifies the citizens about the demand through SMS/Email. The generated Bills can also be grouped and printed for physical distribution by the ULB employees. The system provides the capability to Employees to merge and download bills based on given parameters to plan their distribution drives.

Payments collection and Receipts

The citizen/ employee can view payment status of previous assessments from Assessment History section. Payment for any assessment with full or partially paid amount can be completed. Receipts for assessment can be downloaded in Assessment history section after searching for the property details.

Reports and Dashboards

PT reports provides facility to access receipt register, cancelled receipt register, account receipt register, ULB wise PT collection report, DCB Register. All reports can be downloaded in PDF/XLS format.State level administrator can monitor property tax collections, assessments and other information at a state level through dashboards.

General Features

System specification in compliance with the Ease of Doing Business (EODB) BRAP 2019

List of Features- Property Tax

Introduction

DIGIT Property Tax facilitate ULBs and citizens to automate the assessment/ re-assessment of property tax for a property and its demand billing and collection. It also enables the ULBs as well as citizens to process the transfer of title of a property in case of a sale, gift or will and captures the history of ownership.

Module Features

The main features of the product are as given below.

1. Completely automated assessment and re-assessment of property tax against a property.

   1. Online self-assessment process

   2. Integrated workflow for ULB staff to perform the check and approve.

2. Transfer of title (Mutation)

   1. Online application

   2. Integrated workflow for ULB staff to perform the check and approve.

3. Generating the demand

4. Collection of property tax through various modes (Cash, Cheque, POS (Credit/ Debit Card), NEFT/RTGS, Online - Through Payment Gateway)

5. Auto calculation of rebate, interest and penalty.

Module Ontology

State Level

ULB Level

Module Reports

1. Receipt Register

2. Cancelled Receipt Register

3. Demand Register

DIGIT-Property Tax (PT) is a self-serve web and mobile-based, easy-to-use and configurable product that addresses the objectives of municipal corporations and local government to automate all property tax operations, thus providing property tax assessment and payment services to citizens in real-time.

All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.

Section 1: Executive Summary

Overview of the Product

The computerized and automatic Property Tax system offered by eGov, facilitates citizens who seek to pay their Property Tax within any Urban Local Body with a transparent, speedy, hassle-free and user-friendly procedure. Property Tax (PT) is one of the components of a smart city that has the capability of providing the highest revenue of a state. Keeping in mind the benefits associated with the product offered, the proposed system is about to be implemented in 500+ ULBs across the country in 15 states. (For details on product features refer to )

Implementation Methodology for PT

For the offered product, the implementation process can be divided into seven major distinctive stages. Each stage has predefined entry and exit criteria, roles & responsibilities to assure objective monitoring and decision-making for the overall success of the engagement. The whole implementation lifecycle is typical of 38-42 weeks for the State, keeping in mind the entry, and exit criteria defined at the beginning and end of each stage are met on time recommended.

Stage Zero-program setup and onboarding is a pre-requisite for the initiative to kick off and requires setup of the governance model, implementation Team and decision regarding other significant elements of the initiative like funding and procurement process. Stage One requires scoping of the initiative and decisions on the priorities for implementation by the State Implementation Team.

Stage Two - the State Team works on identifying and finding solutions to the significant gaps in the product offered with respect to the need of the State. Stage Three - involves the Configuration and customization of the product offered. This involves working on various aspects of State-specific needs and incorporating them into the product offered.

Critical Success Factors For Implementation

Implementation of Property Tax (PT) requires meticulous planning and close coordination between various stakeholders at the centre and State levels. The success of the initiative is dependent upon many factors like strong Program governance, availability of trained resources, financial planning, targeted Implementation Team onboarding, focus on last-mile capacity building and ensuring necessary support to the Urban centre. Achievement of all these factors will provide the most effective and efficient roll-out and adoption of the Property Tax System in the State.

Section 2: Property Tax (PT) Product - Overview

The Property Tax System(PT) provides a digital interface to make property assessments, pay property tax, generate payment receipts and monitor tax collection. It can be used by the citizens, Urban Local Body (ULB) counter and field employees and ULB Administrators to accomplish their specific tasks. It is available as a mobile and web-based application. The PT product features can be broadly classified as the following modules:

1. Registration, Login and Creation of User Profile

2. Filling an Assessment for a Property

3. Searching for a Property

4. Modifications to a Property

5. Generate Demand Notice

6. Payments collection and Receipts

7. Dashboards and Reports

8. General Features

Module 1: Registration, Login and Creation of User Profile

This module provides enables the following capabilities

• OTP Based Login for Citizens via Web/Mobile App

• OTP Based Login for Employees via Web/Mobile App

• Provision for language selection during first-time registration for both Employees and citizens

• Provision of creating a personalized Profile for Citizens and employees on the Web App

• Login Credentials for various hierarchies of employees

• Role-based access for performing different actions relating to property tax modules

Module 2: Filing an Assessment for a Property

With this feature, a citizen and employee can perform a self-assessment of a new property for a financial year. This feature helps in registering the property in the system. The details of the property can be entered online and can be assessed for the calculation of the taxes. The PT Product is designed in a user-friendly manner and reduces the chances of error. The system calculates the tax automatically and creates the demand. If a user wants to reassess his property due to any reason (for eg, incorrect data, change in property etc), it can be done by editing the details of the last assessment. Employees can edit the details of the last assessment, on behalf of the citizen based on the owner’s input. A citizen can track down the status of the incomplete assessment. Any incomplete assessment can be searched and completed.

This module provides enables the following capabilities:

• Citizen/CSC can Assess New Property (By Different Financial Years).

• Citizen/CSC can capture Addresses, Assessment, and Owner information for all types of properties like residential houses, flats and commercial buildings.

  Sample Details captured:

  • Door Number,

  • Mutation number,

  • Number of floors,

  • Area covered,

  • Owner and co-owner,

  • Mailing & permanent address,

  • Built year

  • Individual room measurements

• The system computes the property taxes automatically as per the process and rules of the state.

• The system has a facility to make entries in the system by inspector after a site visit and assessment of the same by the superintendent.

• The system supports the dynamic calculation for late fees, interest, rebates, etc. as on the day of demand generation.

• The system fetches the data of the previous year's property data while e-filing for the current year so that all the dues are calculated.

• The system assigns a unique property ID based on the process defined in the ULBs.

• Citizen/CSC: View/Print Summary of Filled Form

  • Assessment Form

  • The assessment form is also sent by email to citizen

• Upload Documents

  • Ownership/Title related

  • ID Proof

  • Any other statutory documents

Module 3: Searching for a Property

Citizens or Employees can track down the status of their incomplete assessment. Any incomplete assessment can be searched and completed.

This module provides the following capabilities:

• Citizens/CSC can search for Property by

  • Mobile No,

  • City,

  • Property Tax Unique ID

• Citizens/ CSC can view Incomplete Assessments

• Citizen/CSC can reassess Searched Property

• View Property Details and pending dues

Module 4: Modifications to a Property

The PT system provides the ability to capture mutation and transfer of ownership. It reduces interfaces between the user and the State and thus promotes greater transparency. It also helps in reducing the time taken for mutation after registration. The system provides the ability for alteration of assessment after verification and inspection.

Any structural changes like addition/extension/reduction of existing built-up area or construction type OR utility changes like usage or occupancy have an impact on the increase/decrease in a property tax demand. These changes can be handled by the ‘Additional/Alteration of Assessment’ feature. The System provides the ability for bifurcation/ amalgamation of property. The property bifurcation/ amalgamation undergoes an approval process. The parent property needs to be modified accordingly, which can be done in the system.

This module provides the following capabilities:

• Mutation of property and change of ownership details

• Capture Extension/ Addition and Alteration and reassessment based on changed property details

• Bifurcation of property

• Amalgamation of property

Module 5: Generate Demand Notice

The system has the capability to automatically generate demand notices for a financial year based on set triggers like time-based rollover on completion of a financial year. The system notifies the citizens about the demand through SMS/Email. The generated Bills can also be grouped and printed for physical distribution by the ULB employees. The system provides the capability for Employees to merge and download bills based on given parameters to plan their distribution drives.

This module provides the following capabilities:

• Generate Demand Notice based on a periodic basis

• Group Demand Notices

• Print Demand Notices

• Cancel Demand Notices

• Send notifications to citizens on demand generation- SMS, Whatsapp, Email, Physical bill

Module 6: Payments collection and Receipts

The citizen/ employee can view the payment status of previous assessments from the Assessment History section. Payment for any assessment with full or partially paid amount can be completed. Receipts for assessment can be downloaded in the Assessment history section after searching for the property details.

This module provides the following capabilities:

• Payment of Property Tax -Online, Cheque, Cash, DD, during the assessment

• Partial Payment of Property Tax -Online, Cheque, Cash, DD, during the assessment

• The system allows a citizen to pay for anyone's property without changing the demand

• The system can also be integrated with PoS machines to enable doorstep collection of property tax and the issue of a receipt.

Module 7: Reports and Dashboards

PT reports provide the facility to access the receipt register, cancelled receipt register, account receipt register, ULB-wise PT collection report, and DCB Register. All reports can be downloaded in PDF/XLS format. State-level administrators can monitor property tax collections, assessments and other information at a state level through dashboards.

This module provides the following capabilities:

• State Dashboard: View Reports for Total Collections, Properties Assessed, ULBs on Prod, Usage Type, Payment Distribution

• State Dashboard: PT Collection Timeline (Monthly, Weekly)

• State Dashboard: ULB Wise (Collection, Assessments)

• Cancelled Receipt Register Report

• PT Collection Report (ULB/Date Wise)

Module 8: General Features

Notifications

The system has the capability to send notifications to citizens. These notifications can be sent for various steps like - assessment completion, payment reminder, and payment confirmation. These notifications can be sent in the language chosen by the ULB through all channels - SMS, Whatsapp, and Email.

Legacy Data Migration

The system has the capability to migrate Demand and Collection. In most states, the preliminary step would be to migrate Legacy data of existing properties/connections along with the Demand and Collection details. This would ensure that subsequent demand generation happens through the system.

Configurable Masters

The system provides the following masters that can be configured as per the State’s requirements:

• Charges & Calculation: Calculation Engine, Rebate, Penalty,

• Rate Master

• State Masters: Property Ontology, Documents List, Employee Data Mapping, Boundary Data Mapping

Section 3: Property Tax (PT) Implementation Methodology

This section provides an overview of the methodology for State-wide implementation of PT. The Implementation of PT is distributed across seven distinct stages. Each stage has predefined entry & exit criteria and roles & responsibilities. This is to ensure objective monitoring and decision-making for the overall success of the program. Details of each stage are defined in this section.

PT implementation program is expected to be completed approximately between 38- 42 weeks depending on the variety of Processes, Integration and the Disparate legacy data systems involved. This is done with the resource deployment by the State and System Integrator (SI) Team. However, it is critical that activities and exit criteria set for each stage are achieved to adhere to this timeline.

Seven Stages of Implementation

Stage 0 - Program Setup/Onboarding

This is a set of initial critical activities undertaken on receiving a letter of Enrollment or MOU from the State. Successful completion of these activities assures that the program is started with crucial personnel, System Integrator(SI) Teams, and funds.

System Integrator(SI) Sign-up

• System Integrator and state will agree on program scope, program timelines, and budgeting & resourcing.

Stage 1 - Program Kick-Off

This stage envisages in-person interaction of crucial State officials and implementation System Integrator(SI) Teams to kick-start the program. This stage may require multiple interactions/meetings with different interest groups. The principal objective of these interactions is to identify and agree on the scope and exclusions of Pilot ULBs, create an active collaboration & Governance approach and agree on a high-level timeline for the engagement.

Stage 2 - Solution Design

During the Solution design stage, key State officials and members, who are subject matter experts, are expected to share their inputs, discuss the process and help understand how to bring in compliance around the system design for the System Integrator(SI) Team. This stage baselines the State-specific product features in the Product Configuration report.

Stage 3 - Configuration & Customization

This stage consists of a series of developments in accordance with the detailed project plan to ensure the smooth functioning of the customised product. Master Data Collection & Environment Setup will be achieved in this phase. Further monitoring and maintenance strategies are put in place.

Stage 4 - UAT & Go Live

During this stage, a demonstration of the product followed by a hands-on session is conducted for the ULB officials. Necessary training of ULB officials and resources required for UAT is conducted and identified respectively. The establishment of the State Support Team and required processes are initiated in this stage.

Stage 5 – Rollout

On successful Go-Live in the Pilot ULBs, and further fine-tuning to stabilize the product, the solution will be rolled out to the rest of the ULBs in phases. Guidance and support from the State Team will be required to create the rollout plans and assure the necessary infrastructure for training and deployment is available at each ULB.

Stage 6 – Sustenance and Ongoing Improvement

The final stage consists of strategies to ensure the sustenance of the program in the State. Systems are put in place to ensure the continuous tracking of data and provisions are made to improve the product if new data suggest.

Section 4: Roles and Responsibilities

PT Cell, eGov Team & System Integrator(SI)Team

This section outlines the activities involved in each stage of the implementation along with the responsibility and accountability of critical stakeholders - State, eGov Team and System Integrator Team onboard.

PT Cell: PT Cell is the government-appointed body chaired by the Principal Secretary/Secretary, Urban Development Department with members from Urban Development Department etc.

Resource requirements for the PT cell required to be formed by the State

Guidelines to read the tables below:

Execute - One who owns the accountability to complete the activity

Consult - One who may initiate, guide and in the process, handhold the execution of the activity

Once the PT cell and SI team are finalised, their role begins in the following stages.

Overall Program Assumptions

Glossary

Vision: Defining the time frame to go live, the time frame to scale it pan state, the value proposition of the programme for the state and year-on-year financial targets and adoption targets

Project Plan: A detailed plan of Program schedule/timelines, implementation phases, team structure and ongoing support and maintenance required.

System Integrator: The Entity/Company which collates all the subsystem required for the project and integrates them to achieve the program objective

Program Charter: Outline of implementation plan agreement with priority applications and broad timelines, program governance model, program success metrics and capacity building.

Acceptance Letter/MOU: Formal Acceptance/Sign Off of the Client State with a clear mandate of the Program

Program Success Metrics: Defining the parameters (which are measurable) prior to the program, on which the success of the program is to be measured on the completion of the program

Project steering committee: The key body within the governance structure which is responsible for the business issues associated with the project that are essential in ensuring the delivery of the project outputs and the attainment of project outcomes.

Project governance: Set of policies, regulations, functions, processes, procedures and responsibilities that define the establishment, management and control of projects, programmes and portfolios.

Scoping: List of activities measured against the time taken to complete them in accordance with the project goals

Baseline data: Set of information that serves as a foundation to compare other data acquired afterwards

Project Kick-off meeting: Meeting with the project team and the client of the project. This meeting would follow the definition of the base elements for the project and other project planning activities

Fitment Study: GAP Study of the Existing/Required Field Process Vs Product

Data migration: Existing Records of the functional activities need to be moved into the Database of the newly released Application

Data collection: Required data for the roll-out of the applications, which needs to be collected from the existing functional process

Data validation approach: This approach enables the sanctity of the Data with built-in validation by the Design

Data synchronization: The process of establishing consistency among data from a source to a target data storage and vice versa and the continuous harmonization of the data over time.

Pilot Implementation: Any new process is tested out as a pilot in one or two instances before pan implementation

Pilot ULB: The ULBs Selected for the pilot implementation are called pilot ULBs.

Roll out: On successful clearance of the Pilot, the Process/Application/Services are implemented across all Offices/ULBs

Deployment: Deployment defines the complete package of Software components set up in a particular environment

Customisation: Details of changes to be made in the Product to comply with the needed field process

Configuration: Defining existing content such as Options and Variables based on the requirements on the ground

Product walkthrough: Explaining to the users step-by-step a set of actions that they need to take to achieve a specific outcome

Introduction

What does bifurcation of property mean?

• A property is divided into two or more parts.

• New properties which come into existence are called child properties.

• The property that got bifurcated is known as parent property.

• The owner(s) of the parent and child properties remain the same.

• The relationship of child and parent properties is maintained to track the bifurcation.

• Change in ownership of child properties is achieved through the Mutation (Title Transfer) process.

• A building property can be divided into.

  • Building + Building

  • Building + Vacant Land

• A vacant land property can be divided into vacant lands only.

How is the bifurcation of property accomplished on the ground?

The bifurcation is considered a service and the owner(s) has to apply for it. An application is submitted for a property bifurcation with the required supporting documents. There is no fee associated with the bifurcation of property application.

Key Metrics

Below are state-wise approximate figures of amalgamation applications received and processed in a year.

Proposed Solution

How to achieve this with the DIGIT Platform?

1. A new application type ‘BIFURCATION’ is created.

2. The no. of properties resulting due to bifurcation is restricted to five which is configurable and can be changed according to the need of implementations.

3. Application no. the format is defined and configured.

4. Only one application is created and the record of the same is maintained and the new properties created as a result of bifurcation are linked to that application.

5. The workflow component is integrated.

6. The status of parent and child properties is maintained as ‘In Workflow’ while the application is in flow.

7. On the approval of the application, bifurcation comes into effect and all the properties become active.

8. Newly created properties are given a new property ID.

9. Though there are no instances where the application fee is charged for bifurcation, the applicability of the application fee is to be made configurable.

10. Bifurcation comes into effect from the date of approval of the application.

11. No final document is generated as proof of bifurcation.

12. Applicant(s) is/are intimated through SMS/ email notifications about the status and completion of the application.

Validations

1. The parent property should be an active property.

2. Ownership of all the properties (parent + child) remains the same.

3. The total land area of the parent property (before bifurcation) should be equal to the total land area of all the properties (parent + child).

4. The total built-up area of the parent property (before bifurcation) should be equal to the total built-up area of all the properties (parent + child).

5. All the child properties inherit the ownership from the parent property.

User Persona

Navigation

Employee

Login → Search Property → View Property Details → Select ‘Bifurcate Property’ Action.

Citizen

Login → Bifurcate Property → Search Property → Search Result → Select Property.

Application No. Format

Application no. should follow the given format - PT-<runningsequence>

User Flow

1. Citizen/ Counter Employee - Application is initiated by citizen/ counter employee.

2. Document Verification - The application and documents attached to it are verified by a document verifier.

3. Field Inspection - The field inspector performs the field visit for the physical verification of properties.

4. Approval of application - In the case no application fee is applicable, the application is approved and bifurcation comes into effect with approval.

5. Payment of application fee - In the case the application fee is applicable, bifurcation comes into effect only after the payment of the application fee.

Application Form

Child Property Form

Workflow

Wireframes

Figma Link - https://www.figma.com/file/AXXM9veAvX5IRazkhwbvqF/Digit-Design-System?node-id=38193%3A82388

Screenshots

Use Case Scenarios

UC1: There is property ‘A’ which has to be divided into 2 properties of the same usage and in the name of the same owner(s).

1. One new property ‘B’ record is created keeping the address and owner(s) details the same as property ‘A’.

2. New door no. is provided to property ‘B’.

3. Assessment detail is added to newly created property ‘B’ keeping usage the same as ‘A’.

4. Property ‘A’ is modified to change the assessment details while the change in address and owner’s detail is now allowed.

UC2: There is property ‘A’ which has to be divided into 2 properties of different usage and in the same of the same owner(s).

1. One new property ‘B’ record is created keeping the address and owner(s) details the same as property ‘A’.

2. New door no. is provided to property ‘B’.

3. Assessment detail is added to the newly created property ‘B’.

4. Property ‘A’ is modified to change the assessment details while the change in address and owner’s detail is now allowed.

UC3: There is property ‘A’ which has to be divided into 2 properties and for the second property owner(s) to be changed.

1. Property ‘A’ is modified to change the assessment details while the change in address and owner’s detail is now allowed.

2. One new property ‘B’ record is created keeping the address and owner(s) details the same as property ‘A’.

3. New door no. is provided to property ‘B’.

4. Assessment detail is added to the newly created property ‘B’.

5. Once the bifurcation application is closed, a mutation application seeking change in the owner(s) is applied either for newly created property ‘B’ or existing property ‘A’ based on the need.

UC4: There is property ‘A’ which has to be divided into 2 properties and for both properties' owner(s) to be changed.

1. Property ‘A’ is modified to change the assessment details while a change in address and owner’s detail is now allowed.

2. One new property ‘B’ record is created keeping the address and owner(s) details the same as property ‘A’.

3. New door no. is provided to property ‘B’.

4. Assessment detail is added to the newly created property ‘B’.

5. Once the bifurcation application is closed, mutation applications seeking change in the owner(s) are applied for newly created property ‘B’ and existing property ‘A’.

Introduction

The request to change in owners associated with a property in municipal record is known as mutation or transfer of title. To process this request and make the necessary changes in the property records ULBs charge for a fee which is calculated based on the fee defined based on a few parameters.

Data Table

Procedure

Data Definition

Steps to fill data

1. Download the data template attached to this page.

2. Refer to the ‘Data Definition’ section of this document to understand the headers in the template sheet, their data type, size, and definitions.

3. Reach out the person who shared the template for further details or to clear your doubts. Identify if the State/ULB has a provision for capturing pipe size for connections.

4. Identify usage wise mutation fee amount and fill into the given template.

5. Go through the checklist to verify the data. Make sure that each and every point mentioned in the checklist is covered.

Checklist

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

Not Applicable

Attachments

Introduction

Rebate is provided on early payments which are done in month April in every financial year at the rate of 5% when the property is paid fully up to prevailing financial year demand.`

Data Table

Procedure

Data Definition

Steps to fill Data

1. Download the data template attached to this page.

2. Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.

3. In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.

4. Get the rebate rate and the amount involved with it.

5. Get the year and the end date for the rebate period.

6. Start filling the template from the right which is the rebate percentage and end it with the rebate end date.

7. Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.

Checklist

The checklist is a set of activities to be performed one the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

Not Applicable.

Attachments

Introduction

Unit rates are also an important part of property tax. The property tax for a property is calculated on the area covered by the property. These unit rates could differ from ULB to ULB, Ward to Ward, Mohalla to Mohalla and then can be based on different parameters such as Road Type, Property Construction Type etc.

Data Table

The data given in the table is sample data.

Procedure

Data Definition

Steps to fill the data

1. Download the data template attached to this page.

2. Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.

3. In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.

4. Figure out on what boundary types are the property tax unit rates being defined and start filling that with its code and its name in English in the boundary code and boundary code name column.

5. In case there are more parameters on which the unit rates are being classified such as road type, construction type is being classified, start making a different column for the same starting from parameter 1, parameter 2…

6. Make sure you replace the column name from parameter 1 to the classification on which it is being classified.

7. At the end fill up the unit rates column.

8. Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.

Checklist

The checklist is a set of activities to be performed once the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

Not Applicable

Attachments

Introduction

Taxes are calculated based on the type of property and differ for each type.

For example, a residential property could have a different rate than a non-residential property, which could differ from year to year.

The tax could be a general property tax or a new type of tax introduced.

Data Table

The data given in the table is sample data.

Procedure

Data Definition

Steps to fill Data

1. Download the data template attached to this page.

2. Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.

3. In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.

4. Gather the details for all the types of properties and the type of taxes levied on them.

5. Start filling the type of tax and the property type from the first column and then start defining the rates and year of application.

6. Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.

Checklist

The checklist is a set of activities to be performed once the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

Not Applicable

Attachments

Introduction

This is the amount which is calculated on percentage defined and collected from citizen if failed to pay the property tax demand on time. It is also called the late payment penalty.

Data Table

The data given in the table is sample data.

Procedure

Data Definition

Steps to fill Data

1. Download the data template attached to this page.

2. Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.

3. In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.

4. Get the interest rate that is being levied over a period of time.

5. Get the year as well as the date from which this was brought in place.

6. Start filling the data from the interest rate followed by the rest of the details.

7. Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.

Checklist

The checklist is a set of activities to be performed once the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

Not Applicable

Attachments

Introduction

What does amalgamation of properties mean?

Two or more than two adjacent properties of an owner(s) are merged to form a single property. On merging of properties, merged properties are removed from the assessment registers while the retaining property is modified to add the merged property(ies) dimensions. The retaining and merged properties relationship is maintained for future reference. The combination of properties for which amalgamation can be done is given below.

• Building + Building

• Building + Vacant Land

• Vacant Land + Vacant Land

How is the amalgamation of properties accomplished on the ground?

The amalgamation is considered a service and the owner(s) has to apply for it. A single application is created for the amalgamation of properties with details of all the properties and the required documents are produced in support of the application. There is no application/ processing fee associated with the amalgamation of properties.

Key Metrics

Below are state-wise approximate figures of amalgamation applications received and processed in a year.

Proposed Solution

How to achieve this with the DIGIT Platform?

1. A new application type ‘AMALGAMATION’ is created.

2. Application no. format is defined.

3. Only one application is created and the record of the same is maintained. All the properties involved in amalgamation are linked to that application.

4. Workflow components are integrated and the wf status of retaining and merge properties are maintained as ‘In Workflow’ while the application is in flow.

5. Though there are no instances observed where the application fee is charged for amalgamation, the applicability of the application fee is to be made configurable.

6. The uniqueness of the owner (Individual) is identified based on the below-given attributes.

   • Owner’s Name

   • Owner’s Gender

   • Owner’s Guardian Name

   • Relationship with Guardian

7. The uniqueness of the owner (Institutional) is identified based on the below-given attributes.

   • Institute Name

   • Institute Type

   • Authorised Person Name

8. No final document is generated as proof of amalgamation.

9. Applicant(s) is/are intimated through SMS/ email notifications about the status and completion of the application.

10. Any integration impact to be handled.

    • Water and sewerage connection with merging properties to be moved to retaining property or to be brought to closure.

    • Trade licenses associated with merging properties are to be moved to retaining property or to be brought to closure.

11. Modules linked with property tax have to expose the API to check the status of applications in respective modules associated with a property.

Validations

1. All the properties should be active properties, INACTIVE and WORKFLOW properties are not eligible for amalgamation.

2. There should be any application in flow for other services as well linked with a merging property. E.g. Water Connection, Sewerage Connection, and Trade License.

3. The owner (s) of the retaining property should always be a superset of the owner(s) of the merging property. It means there should not be a case where any owner of the merging property(ies) is not the one from the owners of the retaining property.

4. There should not be any due on the properties which are to be merged while there is no such condition for retaining property.

5. Dues related to water and sewerage charges for the connections associated with merging properties are not taken care of here.

6. The total land area of retaining property = Land area of retaining + Total land area of properties to be merged.

7. The total built-up area of retaining property = Built-up area of retaining + Total built-up area of properties to be merged.

8. Properties to be merged are deactivated on completion of the process while retaining property remains active.

9. Amalgamation will be effective from the date of approval of the application.

Integrations Impacts

Water and Sewerage

1. There should not be an application related to water connection linked with a merging property in the workflow.

2. In the case of water and sewerage connections associated with merging property to be moved to retaining property, it has to be achieved in the WnS module itself by modifying the connection.

3. In the case of water and sewerage connections associated with merging property to be closed, it has to be achieved in the WnS module itself by using closure connection activity.

Trade Licenses

1. In the case of trade licenses associated with merging properties to be moved to retaining property, it has to be achieved in the TL module itself on renewal of trade.

2. In the case of trade licenses associated with merging properties to be closed, it has to be achieved in the TL module itself by using the closure of trade features.

Accounting and Finance

Accounting entries are passed for these transactions in terms of demand modifications.

User Persona

Navigation

Employee

Login → Search Property → View Property Details → Select ‘Amalgamation’ Action

Citizen

Login → Amalgamation Menu → Search Property → Search Result → Select Property.

Application No. Format

Application No. should follow the given format. PT-<running sequence>

User Flow

Citizen/ Counter Employee - Application is initiated by citizen/ counter employee.

Document Verification - The application and documents attached to it are verified by a document verifier.

Field Inspection - The field inspector performs the field visit for the physical verification of properties.

Approval of Application - The application is approved by the approver and the changes requested in the application come into effect in case the application fee is not applicable.

Payment of application fee - In the case the application fee is applicable, the changes related to amalgamation come into effect only after the payment of the application fee.

Application Form

Workflow

Wireframes

Please click here to see the wireframes in Figma.

Screenshots are attached below.

Citizen (Mobile First)

Apply for amalgamation

Login into the account (If not already logged in)

Select retaining the property for amalgamation

The user will be displayed all the properties currently linked with the logged-in account and allowed to select one of them as a retaining property.

The retaining property address and ownership details is displayed on apply.

Select a property to merge

The user will be displayed a list of all those properties which are owned by him/ her as a single owner or joint owner and allowed to select a property based on the below conditions.

• The owner(s) of the merging property should be a subset of the owner(s) of the retaining property.

• There should not be any dues on the property.

• The property should be active property, also there should not be any application in flow for an integrated module associated with the property.

• The property should belong to the same locality as the retaining property.

Modify the assessment details of retaining property

• Property Type

• Plot Size

• Number of basements

• Number of floors

Unit details

• Usage

• Sub-usage

• Occupancy

• Built-up Area

• Annual Rental

In case the property type is ‘Flat’, flat details are modified.

In the case property type is vacant land, vacant land details are modified.

Documents attachment and summary of the application

Employee

Apply for amalgamation

Property is searched and property details are viewed.​​​​

Select the action ‘Amalgamate Property’ from the action list.​​​​​​​​​​

Use Case Scenarios

UC 1 - Same Owner’s Residential Properties

There are two properties A and B, both are residential in nature and belong to the same owner “xyz”.

Illustration: Suppose A is the retaining property while B has to be merged with A.

• Property A address remains unchanged.

• Property A ownership details remain unchanged.

So assessment details of property A are modified according to the assessment details of B. Below given are the activities which can be performed to modify the assessment detail of property A.

• The land area of A is increased to include B into A.

• One more UNIT is added to A representing B.

• An additional floor is added to A representing B.

• The existing UNIT area of A is increased.

• The existing UNIT rental value of A is increased.

• The remaining attributes would remain unchanged. Like Usage, Sub Usage, and Occupancy. Though these also can be edited if required.

Property B is linked with the application which is deactivated on completion.

UC 2 - Same Owner’s Mixed Properties

There are two properties A and B, A is residential while B is non-residential and belongs to the same owner “xyz”.Illustration: Suppose A is the retaining property while B has to be merged with A.

• Property A address remains unchanged.

• Property A ownership details remain unchanged.

• So assessment details of property A are modified according to the assessment details of B. Below given are the activities which can be performed to modify the assessment detail of property A.

  • The land area of A is increased to include B into A.

  • Property usage is changed to Mixed.

  • One more UNIT is added to A representing B and UNIT usage and sub-usage is kept according to property B, commercial in this case.

  • An additional floor is added to A representing B.

  • The existing UNIT area of A is increased.

  • The existing UNIT rental value of A is increased.

• Property B is linked with the application which is deactivated on completion.

UC 3 - Solo Owner Of One Property And Joint Of Others

There are two properties A and B, “xyz” is the only owner of property A while he/she is the joint owner of property B.Illustration:

• In case, property B is the retaining property, property A is merged according to usage cases #1 and #2.

• In case, property A is the retaining property, property B is first mutated in the name of the owners of property A using the mutation process.

UC 4 - Properties Of Two Different Owners

There are two properties A and B, the owner of property A is “xyz” while the owner of property B is “def”.Illustration:

• In case A is going to be retaining property, property B is to be first mutated in the name of “xyz” using the mutation process.

• In case B is going to be retaining property, property A to be first mutated in the name of “def” using the mutation process.

There are two properties A and B, the owner of property A is “xyz” which is institutional ownership while the owner of property B is “def” which is individual ownership.

• It is a similar case to #4, and the property is to be mutated first to initiate amalgamation.

Introduction

This is a further sub-classification of the ownership which details what is the ownership sub category, whether there is a single owner, multiple owner etc. . An example has been given in the attachments section of the page.

Data Table

The data has to be collected for all the subcategories of ownership type present in the state. Below mentioned is the table of the template that is being used to gather data:

Procedure

Data Definition

Steps to fill Data

1. Download the data template attached to this page.

2. Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.

3. In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.

4. Download the data template attached to this page.

5. Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.

6. In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts. First, get all the sub classifications for the listed category.

7. Get the codes and start filling the template.

8. Fill in the codes for the sub category in the 2nd column with the proper mapping of Ownership Type category (Parent level).

9. Repeat the steps for all the ownership type categories(Parent Level).

10. Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.

Checklist

The checklist is a set of activities to be performed once the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

This checklist covers the activities which are specific to the entity.

Attachments

Introduction

The Usage category could be more detailed out on classifying them further and detailing more specifically on what kind of usage it is such as hotel, shops, community centre etc.

Data Table

Below mentioned is the definition of the template which is used in data gathering:

The data given in the table is sample data.

Procedure

Data Definition

Steps to Fill Data

1. Download the data template attached to this page.

2. Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.

3. In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.

4. Gather all the details for this last classification of Usage Category Detail.

5. Figure out the codes, if not present abbreviate the description so that it creates relevancy between code and description.

6. Get the relations to the sub minor, minor and major.

7. Start filling the template with the codes and description of the usage Category detail and then followed by relative sub minor codes.

8. In the active column fill up whether the category is still active or not.

9. Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.

Checklist

The checklist is a set of activities to be performed on the data that is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

This checklist covers the activities which are specific to the entity.

Attachments

Introduction

Ownership is the state or fact of exclusive rights and control over property, which may be an asset, including an object, land or real estate, or intellectual property. Ownership involves multiple rights, collectively referred to as title, which may be separated and held by different parties. Further, the ownership can be categorised based on the nature and type of the parties property is owned by e.g Property owned by an individual who is the resident of the city, by an institution etc.

Data Table

Given below is the sample data table from the template in which the data has to be collected:

Procedure

Data Definition

Steps to fill Data

1. Download the data template attached to this page.

2. Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.

3. In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.

4. Firstly Identify all the categories of the owners present in the state.

5. After which identify the codes of all the categories, if not present then form an abbreviated version of the code.

6. Start filling the template with the codes in the second column, its English name in 3rd and Local Language name in 4th.

7. Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.

Checklist

The checklist is a set of activities to be performed once the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

Not Applicable

Attachments

Introduction

The Owner’s Special Category represents those property owners whose property belongs to the “reserved” category as defined by the state. These special categories are entitled to a rebate in the property tax amount, as per the defined categories by a State/ ULB.

Data Definition

The data given in the table is sample data.

Procedure

Steps to fill data

1. Download the data template attached to this page.

2. Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.

3. In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.

4. Identify the “” that exists at a ULB/ State level.

5. Add the “” respectively.

6. Add a description to the Owner Type Name, as per the required language.

Checklist

The checklist is a set of activities to be performed once the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

This checklist covers the activities which are specific to the entity.