A replication package is no longer a polite afterthought. Several Indian finance journals and the international outlets that Indian scholars target now treat the package as part of the submission. Reviewers open it, or they do not. When they do not, the paper is often returned with a request that delays the decision by months. This brief explains how to build a package that a busy reviewer will actually open, run, and trust, using the data environments and constraints that Indian finance researchers face every day. The goal is practical: a package that survives the first fifteen minutes of a reviewer’s attention and then produces the tables that appear in the manuscript.
The demand for replication materials has moved from “nice to have” to “expected” for two reasons. First, desk editors and associate editors have seen too many papers whose reported coefficients cannot be recovered from the described sample. Second, Indian data sources—CMIE Prowess, Ace Equity, RBI DBIE, NSE and BSE corporate filings, SEBI filings, and proprietary bank or mutual-fund data—are often large, restricted, or constructed with multiple filters. A short methods paragraph rarely captures every screen. When a reviewer cannot recover the main coefficient on promoter holding or the exact number of firm-years after the ownership screen, the paper loses credibility even if the economic idea is sound.
International journals that publish Indian finance work (Journal of Corporate Finance, Journal of Banking and Finance, Pacific-Basin Finance Journal, and the better-ranked Indian journals such as IIMB Management Review or Vikalpa) increasingly ask for code and data availability statements. Even when the journal does not mandate public posting, the reviewer who is assigned the paper may still request the files. Preparing the package before submission therefore shortens the revise-and-resubmit cycle. In practice, the time spent assembling a clean package before the first submission is far less than the time spent reconstructing code six months later under a four-week R&R deadline.
A further reason is the rise of team authorship and graduate-student co-authors. The person who cleaned the Prowess extract may have left the department by the time the paper is under review. A self-contained package protects the research record when personnel change. It also makes the contribution easier to teach: a colleague can open the folder and see exactly how the Indian sample was constructed.
A usable package has five elements:
The package does not need to contain every raw download. It needs to contain the cleaned analysis sample and the code that turns the cleaned sample into the published tables. If the raw data are proprietary, the package should contain the code that applied the filters and the exact variable definitions used. Reviewers rarely want the full multi-gigabyte Prowess dump; they want to see that the sample restrictions you describe in Section 3 of the paper are the restrictions that actually produced Table 2.
File names should be plain. Use “01_clean_prowess.do”, “02_construct_sample.R”, “table1_descriptives.do”. Avoid spaces, special characters, and “final_final_v3”. Date the package in the README so that later revisions are obvious. When you revise the paper, copy the entire folder, increment the date in the README, and keep the previous version offline. This practice prevents the common problem of a reviewer receiving code that no longer matches the tables in the current manuscript.
Include a short “session log” or capture the Stata or R output that produced the main tables. A reviewer who sees that the code ran without error and produced the same numbers that appear in the paper will stop looking for hidden filters. The log also documents the software version and any warning messages that can be safely ignored.
Indian finance datasets are usually multi-source. A typical paper might start with Prowess firm-years, merge NSE daily returns, add promoter-holding data from the BSE, and then drop firms that fail an ownership screen. Each step must be documented so that a reviewer can reconstruct the sample without contacting the author. The documentation also protects the author: six months later the original filters are easy to forget.
Create a data dictionary that lists every variable, its source, the exact filter applied, and the number of observations lost at each stage. A simple table works:
Save the intermediate files. Name them after the step: “prowess_raw_2010_2023.dta”, “after_ownership_merge.dta”, “analysis_sample.dta”. A reviewer who wants to check the ownership screen can open the intermediate file and count the observations. If the raw download is too large or restricted, store the filter code and a small validation file that shows the first and last twenty observations of the analysis sample, together with summary statistics that match the paper.
For high-frequency data (NSE tick or minute data, mutual-fund portfolio holdings), document the exact vendor file names and the date range. Note any corporate-action adjustments and the source of the adjustment factors. Reviewers who work with Indian equity data know that unadjusted prices produce nonsense returns; they will look for the adjustment step. State whether you used the vendor’s adjusted series or constructed the adjustment yourself from the corporate-action file. If you used a third-party library (for example, a Python package that pulls NSE data), record the version and the date of the pull.
When the paper uses both annual and quarterly data, show the merge keys and the treatment of unmatched observations. Many Indian firm-level papers lose a surprising number of observations when quarterly promoter holdings are matched to annual Prowess fundamentals. Document whether you require a match in every quarter or allow a single missing quarter. The choice affects both sample size and the economic interpretation of the ownership variable.
Place the code in a flat folder with numbered scripts. A typical structure is:
replication/
README.md
data/
code/
01_import.do
02_merge.R
03_construct_variables.py
04_main_tables.do
results/
notes/
Each script should begin with a short header that states its purpose, the input files it expects, and the output files it produces. Use relative paths only. Hard-coded absolute paths (“C:/Users/Name/Desktop/data”) fail the moment the reviewer downloads the zip. Relative paths also make the package portable across Windows, macOS, and Linux machines that Indian departments and international reviewers use.
Declare dependencies at the top of the first script or in a separate “00_setup” file. For Stata, list the exact version and any user-written commands (ssc install). For R, use a renv lockfile or at least a list of packages with versions. For Python, include a requirements.txt. Reviewers will not hunt for missing packages. A one-line comment such as “Requires Stata 17 or later; user-written commands: reghdfe, ftools” prevents the first error message from ending the reviewer’s patience.
Make the scripts deterministic. Set random seeds where sampling or bootstrapping is used. Sort data before merges. Avoid interactive commands (browse, edit). The package should run from a clean session with a single master do-file or a simple shell script that calls the numbered files in order. If the analysis uses multiple cores or parallel processing, document the number of cores and provide a single-core fallback so that a reviewer on a laptop can still run the code.
Test the package on a second machine before submission. If you only ever ran the code on your own laptop, the reviewer will discover the missing package or the absolute path. A short note in the README that says “Tested on Stata 17 and R 4.3 on Windows and Ubuntu” reassures the reviewer that the code is portable. Ask a research assistant or a colleague in another department to perform the test; their fresh eyes catch path problems that the original author no longer sees.
For papers that combine Stata, R, and Python, decide on a single master language or provide a clear order of execution. A common pattern is to clean and merge in Stata or R, export a clean analysis file, and then produce tables in whichever language is most convenient. Document the hand-off files so that a reviewer who prefers only one language can still verify the main results.
Many Indian finance papers use data that cannot be posted publicly: proprietary bank loan tapes, mutual-fund portfolio holdings under non-disclosure agreements, or firm-level survey data covered by an institutional ethics clearance. The package must still be usable. The objective is to give the reviewer enough material to verify the computational steps without violating the agreement or the clearance.
Provide a data-availability statement that is precise. Write: “The proprietary bank loan tape cannot be shared under the NDA dated 15 March 2024. The code that constructs the analysis sample from the tape is included. A synthetic sample with the same structure (but scrambled firm identifiers and perturbed values) is provided in data/synthetic_sample.dta so that the code can be executed.” Reviewers can then run the code on the synthetic data and verify that the tables match the paper’s structure. State clearly that the synthetic numbers will not match the paper’s published coefficients; the purpose is to confirm that the code runs and produces output of the expected shape.
For ethics-clearance papers, include the clearance letter number and the date in the notes folder (redact personal identifiers if required). State the variables that were suppressed to protect respondent confidentiality. If the clearance restricts even the synthetic sample, say so and offer to run any requested robustness checks yourself and return the output within a stated number of working days. Name the person who will respond and give an institutional email address that will remain active.
Never claim that “data are available upon request” without naming the person who will respond and the expected turnaround. Reviewers have learned that “upon request” often means “never.” A concrete sentence such as “Requests for the proprietary extract should be directed to the corresponding author at the institutional address listed in the README; responses are normally provided within ten working days subject to the terms of the NDA” is far more credible.
When the restricted data come from a commercial vendor that allows academic redistribution of derived variables but not the raw file, document the distinction. Include the derived analysis sample and the code that produced it, and note the vendor’s redistribution policy. This practice is common with certain CMIE and Ace Equity extracts once the researcher has applied substantial cleaning.
The README is the only file most reviewers will open first. Keep it short and ordered:
Use plain text or Markdown. Do not embed the full paper. Link to the data dictionary and the ethics note. A reviewer who spends eight minutes on the README and then runs the master script should obtain the main tables without further correspondence. Include a one-sentence statement of the paper’s main empirical claim so that the reviewer can confirm that the reproduced table supports that claim.
Further reading on DrDPKlass: see the earlier Research Series notes on writing an identification section and on converting a PhD chapter into a journal article for complementary advice on methods transparency. Those notes discuss how to describe the same sample construction in the manuscript itself; the replication package simply makes that description executable.
A useful addition is a short “known differences” note. If the package produces a coefficient that differs from the paper by a rounding error or because of a later data update, state the difference explicitly. Reviewers appreciate candour more than an unexplained discrepancy of 0.001.
The packages that reviewers close without running share a short list of defects:
Pre-empt these by running the package from a clean directory on a second computer the week before submission. Ask a colleague who has not seen the paper to open the zip and follow the README. If that colleague cannot produce Table 2 in under thirty minutes, the package is not ready. Record the test in the notes folder: “Tested by [colleague name] on 5 October 2026; Table 2 matched.”
Keep a private “changelog” in the notes folder. When a reviewer asks for an additional specification, add the script, update the README, and note the date. The package then remains the single source of truth. Version the package itself (for example, replication_v1_2026-10-12.zip) so that later correspondence refers to a specific file set.
Another frequent failure is the silent drop of observations inside a merge. Always report the number of observations before and after each merge, either in the log or in a small diagnostic file. A reviewer who sees that the promoter-holding merge dropped 12 percent of firm-years can decide whether the drop is economically material; a reviewer who cannot see the drop will assume the worst.
A replication package that meets this checklist will be opened. It will not guarantee acceptance, but it removes one common reason for delay and signals that the results were produced with care. Build it once, keep it current, and treat it as part of the paper rather than an appendix that can be assembled later. In the Indian research environment, where commercial databases are expensive, personnel turnover is high, and review cycles are long, a well-constructed package is one of the highest-return investments an early-career scholar can make.