A custom report is a named selection over an existing source. You choose the source and which of its columns to include; you do not write a query.
This is deliberate. There is no free-form SQL, no join builder and no filter expression language. A custom report cannot produce data the catalog cannot — it presents the same sources differently.
Building one
Open the builder
Reports → Build new.
Pick a source
The list of runnable sources behind the catalog: daily attendance summary, late arrivals, absentee, punch source, leave balance, leave taken, salary summary, overtime payout, PF/ESI register, TDS, Professional Tax and Form 16 status.The source decides what time filter the report will ask for when it runs.
Choose columns
A subset of the source’s full column set, in the order you want them.
Name it and pick a category
The category decides where it appears in the library.
Choose export formats
Which of CSV, Excel and PDF this report offers.
Why source-and-columns rather than a query builder
Each source is a hand-written generator that already handles organization scoping, the correct joins, and the period semantics for its data. Restricting custom reports to a column selection over those generators means a custom report cannot produce a wrong number, and cannot see across organizations.
The trade-off is real: if your question cannot be answered by narrowing an existing source, it cannot be answered as a custom report. Use the public API for those.
Editing
Name, columns and formats can be changed at any time. The source cannot — a report is tied to its source.
To change a report’s source, build a new one and delete the old. Nothing depends on a report’s identity except its schedule.
Deleting
Custom reports can be deleted. Catalog reports cannot — they are read-only, and deleting one is refused.
Scheduling
Any report, custom or catalog, can be given a delivery schedule — with an important caveat about what “delivery” currently means. See Scheduling and exports. 
