How to prepare a case index (dizi pusulası)

A case index — dizi pusulası in Turkish practice — is a list of the documents in a file: which document comes in which position, what date it carries, and which page of the bundle it starts on. It sits at the very front, ahead of the documents themselves, and it exists for one reason: so that whoever opens the file can locate a document from the list instead of leafing through the bundle.

That person is usually not you. It is the judge preparing for a hearing, opposing counsel reading the file to draft a reply, or you again six months later. In a hundred-page bundle, seeing on one line that the expert report begins on page sixty-three, rather than scanning for it, is the entire justification for the page.

Four fields form the core: a sequence number, the name of the document, its date, and the page it starts on. The Case Bundle tool in Dosya Kalemi builds the index with exactly those four columns — No, Document, Date, Page — and adds a summary line underneath showing how many documents and how many pages the bundle contains.

The document name is not the file name. A name produced by a scanner says nothing about what the document is; the index wants something readable, such as expert report, statement of defence, or bank letter. For the date column, decide in advance which date you are recording. If some rows carry the date the document was drawn up and others the date it was served, the column stops being usable for ordering, and the reader stops trusting it. Keep the format consistent down the list as well.

Some courts also ask for the closing page, whether the document is an original or a copy, or how many pages it runs to. Once you have the order and the starting page, those are derivable; extending the list to match a local expectation does not change how the index works.

The starting page in the index only means something if a continuous number is printed on the pages themselves. The counter your PDF viewer shows in the corner is not a substitute: print the bundle, or split a section off to send separately, and that counter is gone while the index still claims a page. The number has to be on the page.

The usual failure is merging documents that were each numbered on their own. If every pleading starts again at one, a hundred-page bundle contains five different page threes and the index cannot say which one it means. After merging, a single run of numbers has to be printed across the whole body, and that run has to start at one on the first page of the body. The documents keep whatever old numbers they were printed with, but only the new run is authoritative for the bundle.

The index page itself is normally left unnumbered, and there is a solid reason for it. The index runs to one, two, or three pages depending on how many documents are listed. If it were numbered, the body would start at page two in one bundle and page four in another; add one more document and the index can grow by a page, shifting every reference in the list at the same time. An unnumbered cover keeps the page references independent of the number of documents. In Dosya Kalemi this rule is written into the tool: numbering happens before the index is prepended, so the body always begins at page one.

The most expensive mistake is adding a document after the index is finished. Inserting a row is not enough: every starting page below the insertion shifts by the page count of the new document. In hand-kept lists the new row usually gets added and the rows below it stay as they were, so the index quietly becomes wrong. If a document arrives late, regenerating the index is safer than editing a row.

The second is dates that do not match the documents beside them. Mixing the date of issue with the date of service in the same column makes it useless for chronological reading, and a reader who cannot tell what the dates represent will ignore the column altogether.

The third is the order of scanned material. Files coming off a batch scanner sort by name, while the file's real order is chronological or procedural — and in name order the tenth scan can land before the ninth. Checking the order by eye before merging costs far less than recomputing every page reference afterwards.

What the index is called, how its columns are laid out, and whether it is expected at all vary by court, by type of case, and by local practice. In some places it is standard for a thick file, in others it is not asked for, and some offices hand out their own template. Treat what is described here as a working skeleton rather than a rule of procedure.

Where the court or office you are filing with has its own expectation or an established local practice, that takes precedence. The part of the skeleton that does not vary is this: the list works only as long as it agrees with the numbers printed on the body. Once that agreement breaks, a neatly formatted index simply points people to the wrong place.

The Case Bundle tool in Dosya Kalemi handles the three jobs together, because they depend on each other: it merges the documents into one PDF in the order you set, prints a continuous page number across the body starting at one, works out where each document begins, and builds the index and puts it at the front. Reordering the documents by dragging recalculates the starting pages, so the link between the list and the body is not something you maintain by hand.

You give each document the name and date that should appear in the index; the file name is only a starting point. The index page is produced as A4 portrait whatever size the body pages are. If you turn off both the index and the numbering, what remains is a plain merge, and Merge PDF covers that.

The files do not leave your browser while this happens — the merging, the numbering, and the drawing of the index all run on your own machine. For case documents that means the material is not uploaded to a server, which is usually what you want when the papers belong to a client.