tar-rebuttal

R&R Response & Rebuttal (tar-rebuttal)

When to trigger

• You received a TAR R&R and have planned the revision (via tar-review-process)
• You have made (or scoped) the manuscript and code changes and need to write the response document
• You must reconcile conflicting reviewer demands for the editor to adjudicate
• A later-round decision asks you to defend or further revise prior changes

> Write the response after revising the manuscript and the code, not before — the letter

> documents changes you have made, not promises. TAR's process is developmental and typically

> multi-round; resubmit the revised manuscript and response through Editorial Manager

> (editorialmanager.com/accr), keep anonymity intact, and remember the revised submission still

> respects the 55-page budget (references, tables, figures, appendices included).

Response-document structure

1. Opening letter to the editor. Thank the editor and reviewers; summarize the most important

changes in 2–4 sentences; explicitly state how you addressed the editor's stated priorities.

Note where reviewers conflicted and how you resolved it.

1. Per-reviewer sections. For each reviewer (a minimum of two), restate every comment verbatim

or faithfully numbered, then respond.

1. Point-by-point format for each comment:

• Comment (quoted/numbered)
• Response (what you did and the economic/econometric reasoning)
• Location (section/page/table where the change appears)
• Quote new manuscript text where helpful.

How to respond to TAR's signature demands

• "Identification is not clean." Add or strengthen the design — pre-trends/dynamic effects, a

better instrument, a placebo/falsification test, an alternative shock, or a robustness battery —

and explain why it resolves the threat (see tar-methods, tar-data-analysis). Do not argue the

endogeneity away in prose alone.

• "The contribution is incremental." Sharpen what the accounting field learns and reconcile with

the conflicting prior results; revise the contribution sentences, not just citations (see

tar-contribution-framing, tar-literature-positioning).

• "Show the data are authentic / share the code." Provide the data description and **processing

computer code** for public databases, the abstraction methodology plus code for abstracted data,

or sufficient detail / corroborating parties for private data — this is a TAR requirement, not a

courtesy.

• "Add a test / robustness." An additional specification, partition, or (for behavioral work) a

follow-up experiment that nails the mechanism is often decisive — but watch the 55-page budget;

heavy new material usually lives in an online appendix so the main body stays within limit.

Tone and tactics

• Be respectful and substantive. Reviewers are colleagues investing in your paper; engage

seriously even when disagreeing.

• Concede gracefully where they are right; make the change.
• Disagree with evidence, not assertion. If you decline a request, give an economic/empirical

reason and, where possible, an alternative analysis showing robustness.

• Address every point. A non-trivial point left unanswered reads as evasion and can sink a round.
• Surface conflicts to the editor. When reviewers ask for opposite things, explain the trade-off

and your chosen resolution for the editor to adjudicate.

• Preserve anonymity in the resubmission and keep the revised files reproducible.

Checklist

• [ ] Manuscript and code actually revised before the letter was written
• [ ] Editor's priorities addressed first and explicitly in the opening letter
• [ ] Every reviewer comment (min. two reviewers) restated and answered (none skipped)
• [ ] Each response names the location of the change and quotes new text where useful
• [ ] Identification and contribution demands met with real changes, not citations only
• [ ] Data-authenticity / code-access requests satisfied per data type
• [ ] Declined requests justified with evidence and an alternative test where possible
• [ ] Reviewer conflicts surfaced and resolved for the editor; 55-page budget respected

Anti-patterns

• Writing the response before making the changes (or before updating the code).
• Skipping or burying an inconvenient comment.
• Answering "we added a citation" to a "deepen the contribution" or "fix identification" request.
• Arguing endogeneity away in prose with no new test.
• Declining a request by assertion ("we believe this is fine") with no evidence.
• Silently siding with one reviewer when two conflict, leaving the editor to discover it.

Output format

【Decision round】1st R&R / 2nd round / ...
【Editor priorities addressed】1... 2... 3...
【Per-reviewer coverage】R1: x/x comments, R2: x/x (+R3 if any) — all answered? yes/no
【Major changes】identification: ... contribution: ... new test/study: ...
【Data authenticity】code/description provided per data type? yes/no
【Declined requests + justification】...
【Reviewer conflicts resolved】...
【Budget】revised main body ≤ 55 pages? overflow → online appendix
【Next step】resubmit via Editorial Manager; on next decision → tar-review-process