Record a service period as the confirmed span of work it describes, and keep that period distinct from the invoice issue date and payment due date. Retain the start, end and relationship to the billed items where those facts matter. A month name in a description may help a reader, but a structured recipient can require dedicated period fields.
The date and document preparation workflow separates these roles before entry. EInvoiceCreator currently has issue and due date fields, not a complete structured service-period model. Use its readable fields honestly and preserve any additional requirement for supporting software.
Establish what the period covers
Use the agreement, approved work record or relevant billing instruction to identify the period. Do not infer it from when the invoice was typed or the last day a contact replied. The work might concern an agreed month, several individual sessions or a milestone rather than one continuous span.
For a fictional maintenance service, the agreed charge could cover 1 to 30 September. The preparation record should identify that coverage and the actual service being billed. It should not automatically turn 30 September into the invoice issue date or payment deadline.
If the service was interrupted or only part of a period is billable, confirm the facts and charging basis. The editor cannot determine whether a partial period changes the quantity or price. Keep the approval evidence separate from the arithmetic of the values entered.
Keep start and end meaning explicit
Record the confirmed dates and clarify whether the relevant instruction treats the boundaries in a particular way. Do not assume that a vague phrase such as “through September” establishes every date needed by the final profile. Ask for clarification where the period affects the recipient’s matching or required representation.
Check that the start and end relate to the same service. A copied end date from another line can leave a plausible range with the wrong commercial meaning. A calendar-valid date alone does not confirm that the billed work occurred during that period.
The invoice-date and supply-date comparison helps distinguish a period of underlying work from the document-related dates. Keeping those values separate avoids making one available date box carry several inconsistent meanings.
Relate the period to the correct lines
If every line covers the same period, retain that common relationship clearly. If different items cover different periods, record each relationship rather than placing one global note on the whole invoice that appears to apply to all work.
For a fictional consultancy, a September support service and an October workshop may appear in the same preparation record if the agreement and recipient process permit it. A general “September services” note would then misdescribe part of the invoice. Separate descriptions and period records can preserve the facts for review.
If the final profile requires line-level period elements, a descriptive sentence is not an implemented substitute. The current application does not generate those typed structures. Give the external mapper the dates, affected lines and specification requirement so it can represent them deliberately.
Choose readable wording without changing structure claims
A description such as “Monthly maintenance, September service period” can help a person identify the charge where appropriate. More precise start and end dates can be included when they are confirmed and useful. Avoid vague wording that forces the customer to consult unrelated correspondence to understand what was billed.
Do not put the period end in the due-date field just because it is another date input. That would mislabel the payment deadline and may create a contradiction with the written terms. A missing service-period field should remain a model limitation, not a reason to repurpose another role.
The current printable output can show descriptive text, while its application JSON preserves the application’s own limited fields. Neither establishes that a recognised standard’s period requirements have been fulfilled. Keep that boundary clear when handing the preparation to another system.
Review quantities and amounts independently
A period describes timing; it does not automatically establish a quantity or charge. A monthly fixed fee, daily rate and hourly arrangement can use the same calendar span while producing different line data. Use the agreement and approvals to establish the charging basis.
Do not count calendar days and multiply by a price unless that is actually the agreed basis. Likewise, do not reduce a fixed amount by an assumed partial-period calculation without confirmation. EInvoiceCreator calculates the entered quantity and price but does not interpret service contracts.
Confirmed tax treatment also remains separate. The application does not determine the legal significance of a service period for tax timing or rates. Obtain appropriate advice when those questions are material.
Preserve the source and next requirement
Before export, compare the period wording, issue date, due date and relevant lines. Look for an old month label in notes or a period copied to the wrong service. If the work spans several pages, inspect the actual output so the period remains associated with the intended charge.
Keep the approved period and its line relationships with the preparation record. Where formal mapping is still required, identify that task explicitly. Clear period information helps a recipient understand the supply, but it does not by itself establish standards conformance, tax correctness or successful delivery.